We Keep Coding

How do I run nunit 2 tests from nunit-console from the command line?

I have built nunit-console from https://github.com/nunit/nunit-console
and nunit-v2-framework-driver from https://github.com/nunit/nunit-v2-framework-driver referencing nunit-2.7 assemblies from https://github.com/nunit-legacy/nunitv2/releases/download/2.7.0/NUnit-2.7.0-src.zip
I am invoking the mono compiler mcs explicitly, directly from the command line, for each assembly that I build (so that I know what's going on under the hood). The nunit-console assembly produced can run nunit v3 tests as expected.
I have an old project with lots of nunit 2 tests and understand that the nunit-v2-framework-driver can be used to run nunit 2 tests with nunit-console.
I'm not sure how to do this though - how can I get nunit-console to pick up the nunit-v2-framework-driver extension? Referencing the assembly does not seem to be enough.

If you're building from source, you need to add a .addins file, to point the engine to where you have the extension located.
The .addins file should sit next to the nunit.engine.dll assembly, and just contain the path to nunit.v2.driver.addins - which should be included with your nunit-v2-framework-driver build. (Or alternatively, a path to nunit.v2.driver.dll directly)
As an example of how this should look, you might want to download the Console as packaged in NUnit.Console-3.9.0.zip from the GitHub releases page, and take a look at the nunit.bundle.addins file, and the file structure around it.

Feature file execution with NUnit

I am trying to run a feature file with NUnit Console. I tried googling it and checked NUnit3 help also. But I am unable to find any help.
I want to run either single feature file or any scenario in a feature file which has tag assigned. I am using specflow with specrun. I tried NUnit console command for where "test == path of feature file" but it is not executing test. However I am able to execute all test cases by giving project dll file path. But I just want to execute a single feature file or single scenario in a feature file. Please let me know how can I do this so that I will be able to generate NUnit testresult.xml file.
Thanks.

if you are using SpecRun then you can use the command line of SpecRun to run the tests.
If you really want to use NUnit then you first have to make sure that the project containing the feature files has been compiled. Once you have a test dll this will contain the NUnit tests just like any other and the test categories will be set based on the tags, so you can execute them all by telling NUNit to run tests in the test dll, or you can run tests which have a Tag by telling Nunit to run tests which are in a category matching the Tag.
Running just a feature will be more tricky as there is nothing which groups the scenarios by feature in the tests I don't think, though I may be wrong.

instead of test==featurefile use name==FeatureName

Pass parameters to NUnit test

I'm calling nunit test from Jenkins and I need to be able to specify just one URL address as parameter which I can use inside test. Is there possibility to do that?
For example I'm calling "Execute Windows batch command" in Jenkins like that:
"C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe" "D:\selenium\SeleniumTest.dll" /run:SeleniumTest.Test.MyTest
Any ideas?

As far as I currently know of, there is no solution to provide just that what you describe that you want. Best option is to use NUnit project files, modify settings there and pass the solution file to the runner.
On the other hand, you could try to use the Environment variable.
Use set from the command-line. Then read the value using Environment.GetEnvironmentVariable() and use that within your testmethod.

Is there a C# mstest equivalent of system property in Java?

I would like to be able to pass a system argument - "host" to the MStest suite. To create automated jobs for continuous integration, I want to be able to specify the host as a parameter so the tests are run on that specific host. I couldn't find any such option with mstest.
In Java, -Dhost="localhost" would work which can be specified as a parameter for the running VM. Is there a similar way in MStest for C#?

There is not an equivalent to the Java system properties that you mention. Here are a couple of ideas on how to approximate what you are looking for:
[1]
Visual Studio test support does include Test Run Configurations (renamed Test Settings in Visual Studio 2010). This is a file that specifies many settings that control aspects of the test run. For example, you can deploy additional files alongside your test, or run a "setup" batch script before your test run begins.
If you have a finite set of hosts, you could have a separate test run config/test settings for each host. Each config/settings would deploy a file that contains the name of a different host. You could then read in that file as part of your unit test setup, perhaps from your [TestInitialize] method. A bit hokey, but maybe it would do what you want.
[2]
You could set a system environment variable (e.g., "TESTHOST") before running the test, and then read that environment variable from your tests. You could wrap all of this up in a simple program or batch script that accepts an argument to set the environment variable, invoke mstest, and unset the environment variable afterwards. For example, this StackOverflow post may give you some ideas on how you might do something like this using PowerShell.

I don't believe there is an exact equivalent. Instead, try leveraging .NET configuration files:
Add an application configuration file (App.config) to your MSTest project. Add your "system" properties as keys in the appSettings section. Reference these values in your tests using the ConfigurationManager.AppSettings collection.

Can't load DLL while executing tests with MS-Test

In my program, I use SevenZipSharp to generate zip files. SevenZipSharp is a managed DLL which loads another DLL, 7z.dll. I am manually setting SevenZipSharp's path to 7z.dll using SevenZipCompressor.SetLibraryPath.
When I execute my program in Debug mode, this all works fine, and it generates the zip file as nice as you please. However, when I execute my unit tests with mstest, SevenZipSharp always gives me the following error:
Test method threw exception:
SevenZip.SevenZipLibraryException: Can not load 7-zip library or
internal COM error! Message: failed to load library..
I suspect that MSTest might be doing something that is preventing SevenZipSharp from being able to load 7z.dll, like running in a security-tight sandbox (or something. I'm new to C# and MSTest...)
Does anyone have an idea about what might be happening?
Thank you!

Though the question posits a questionable scenario, the general problem of MSTest not loading required DLLs seems to be a common one, deserving of a less dismissive answer.
By default MSTest will copy the assemblies it believes are required by the test container to the Out folder of the default results folder, which changes for each run.
MSTest does not always automatically infer the necessary assemblies correctly; if there is no explicit direct reference to an assembly it won't be copied. Also, native DLLs are typically not detected.
I am not aware of a direct option to set the MSTest search path. You can determine the search path using procmon.exe as suggested above (it is basically the standard Windows DLL search).
Unintuitively, the default search path does not include the launch directory and I think this is a cause of confusion. When the tests are running the current directory is the test results "Out" directory, not the MSTest launch directory.
However, it is possible to control MSTest search behaviour (and the copying behaviour) with a test settings file. You can easily create and edit these through Visual Studio (see the Test menu) and then specify the created settings file on the MSTest command line. You can use different settings files for Visual Studio and MSTest.
By this means you can control exactly what DLLs are copied to your test directory.
See Create Test Settings to Run Automated Tests from Visual Studio to get more information on this.
Of course, DLL load failures may be due to missing dependencies, and the DLL mentioned in the error message may itself be present. You can use the dependency viewer or procmon to pick up unexpected dependencies in DLLs.

Consider using Process Monitor (aka procmon.exe) from the excellent SysInternals tools to monitor your test harness (MSTest). It will show you where the executable is looking for 7z.dll.

Visual Studio 2017 (and possibly 2015) provides two new ways to indicate that a native dll or other file is required by your tests without the need for a test settings file:
1: Add a link to the dll to your test project and tell VS to copy it to the output directory. Right-click the project in Solution Explorer and choose Add > Existing Item. Browse to 7z.dll, click the down arrow next to the Add button, and choose Add as Link. Then select the new 7z.dll item in Solution Explorer, alt-Enter to bring up Properties, and set "Copy to Output Directory" to "Copy if newer" (or "Copy always").
2: Attach a DeploymentItemAttribute to your test class. This attribute's constructor takes a single string argument, which is the path to the file you want to make available to tests in the class. It is relative to the test project's output directory.

Are you sure you want your unit tests to involve external libraries? Ideally you should have mechanisms to replace external stuff with e.g. mock objects, because testing external libraries like that actually turns your test into an integration test.
For popular libraries such as SevenZipSharp you can assume that it is properly tested, and you can have manual integration tests to verify that it performs correctly in your program.
I would consider getting rid of that dependency through dependency injection, mocking frameworks, etc, and let your unit tests solely test your own code.
Investigate the factory method or abstract factory design patterns for tips on how to easily replace such dependencies.
A good start would be to create your own ICustomZipInterface, and use the wrapper pattern to encapsulate your zip logic for production code. In your unit tests, replace that wrapper class with a dummy implementation. The dummy implementation might for example record how you access your zip component and you could use that information to validate your code, rather than checking if a zip file is actually created.