https://github.com/nunit/docs/wiki/Result-Writers
I'm trying to write customresults for my application using Nunit. But I'm not getting anywhere as I am not able to find any sample on how to implement. Any idea?
[Extension]
[ExtensionProperty("Format", "custom")]
public class CustomResultWriterFactory : IResultWriter
{
...
}
It seems that your question is not really about how to implement a writer (since you have already done that) but how to install it so that NUnit will use it. Is that correct? In any case, that's what I'm answering. :-)
I could be more specific if I knew how you are using NUnit because (unfortunately) there are some differences in what you have to do. I'll assume you run tests using the NUnit console runner, since that's the only way to use the format option. Further, I will assume you installed the console using the nuget package. If you did something else, minor adjustments are needed to the steps you should follow.
Look in the directory where the console runner and engine are installed. It should be in something like packages\NUnit.ConsoleRunner.3.8.0\tools depending on the version you are using.
You should see nunit.engine.dll in that directory as well as a file named nunit.nuget.addins. That .addins file is set up to find any extension packages, which are also installed using nuget. If you had a nuget package for your own extension and installed it, NUnit would find it immediately. Let's assume you do not, however.
In the same directory, create a new text file with file type .addins. You can use any name, so long as it doesn't conflict with any other file in the directory. Edit the file so it contains one line with the absolute or relative path to your extension. For example:
....\my\extensions\CustomReportWriter.dll
Run the console runner with the option --list-extensions. You should see your extension listed.
Run the console specifying --result:path/to/result/file.result.xml;format=custom. You should get your custom output.
NOTE: As you see, I made a lot of assumptions, which could be wrong. That's because you didn't give us a lot of info in your question and I felt this was friendlier than just saying "Write better questions!" But please learn how to write better questions that give all the information needed to help you. :-)
Related
I need to run my Speflow feature file with Nunit 3.6 console. Just need to know how can i run specific feature? As fixure is not supported anymore so just need to know what else can be used? Tried --test = but no luck.
I've tried below command line
%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "C:\jenkins\workspace\Nunit_ME_Test\Automation\Automation.csproj"
C:\nunit\nunit3.7.0\nunit3-console.exe C:\jenkins\workspace\Nunit_ME_Test\Automation\bin\Debug\Automation.dll --test=ME_NTJ_Include
I have used -test=ME_NTJ_Include where "ME_NTJ_Include" is the feature file .I'm sure something is not right , can any one please help to resolve this .
Thanks
To learn exactly how SpecFlow is naming your tests at different levels, simply run all of them and examine the XML result file. The name you find there for FullName is what you would have to use with the --test option. Most likely, you are simply issing the namespace in which the fixture is defined.
For more flexibility, use the --where option. That would allow you to write, for example --where test=~ME_NTJ_INCLUDE for a partial match of the name.
I have programmed an console application with c# for ranorex automation.
Within the exe i have build i would like to kick off the specflow feature files manually.
I believe I need to create a TestRunnerManager and trigger the run.
Can anyone help?
Although not familiar with nunit, I guess like with mstest, attributes are used to mark methods in an assembly as tests. You could use reflection to find these methods in the assembly and invoke them
This question is similar in spirit to one I asked a while back about MsTest (How do you run SpecFlow scenarios from the command line using MSTest?).
Remember that SpecFlow feature files become C# classes. Scenarios within a feature file become test methods. You can use the nunit-console command line utility to run these:
nunit-console /fixture:Your.Test.Project Your.Test.Project.dll
Which should run all the tests in the Your.Test.Project namespace.
When annotating scenarios using #CategoryName:
#Feature1
Scenario: Some cool feature
Given ...
You should be able to run those from the command line as well:
nunit-console /include:Feature1 Your.Test.Project.dll
Note: This is from an older version of NUnit. Current documentation: https://github.com/nunit/docs/wiki/Console-Command-Line
I use MsTest with Specflow, so my examples might not be correct, but this should put you on the right path. Just look at the *.feature.cs files generated by the .feature file to give you some hints.
No need to create your own console application to run these tests. Worst case scenario, create a batch file or PowerShell script to kick off the tests you want.
I've decided to use RoundhousE for my database. Now there are three ways to use this tool. With MSBuild, a DLL File or the console application. I found some documentations how to use the MSBuild variant and I know how to use the console application but I can not find anything how to use the DLL in Visual Studio and how to call/configure RoundhousE this way.
Does someone know where to find a detailled documentation or could someone explain me this?
The DLL is used in a few places, like with DropkicK - it may not be a bad idea to explore how it uses it, as there is not much documentation with this otherwise. You can also review how Roundhouse RefreshDatabase uses it as well.
DropkicK - https://github.com/chucknorris/dropkick/blob/master/product/dropkick/Tasks/RoundhousE/RoundhousEClientApi.cs
RoundhousE-EntityFramework RefreshDatabase - https://github.com/chucknorris/roundhouse-entityframework
HTH
I'm trying to run some unit-tests for NxBRE before I start referencing it's implementation in the rules-engine project I'm working on. I'm using versions NUnit 2.6 for testing NxBRE 3.2. Since NxBRE came with it's own unit tests in it's own friendly project folder that utilizes the NUnit.Framework, I figured it'd be a quick one-two outta there ka-poo. After making sure everything compiled, I went ahead and ran the tests...and got a million errors. Mostly along the lines of:
NxBRE.Test.FlowEngine.TestBackwardChainer.CircularityDetection:
SetUp : System.IO.FileNotFoundException : Could not find file 'C:\car-loan-rules.xbre'.
or:
NxBRE.Test.InferenceEngine.TestEngineCoreFeaturesRuleML091.TestEngineCoreFeaturesRuleML09.NxBREOperators:
System.IO.FileNotFoundException : Could not find file 'C:\test-0_91.ruleml'.
Befuddled, I went to the NxBRE website and looked for information about their unit-tests. This was all I could find: http://sourceforge.net/apps/trac/nxbre/wiki/UnitTesting
Which doesn't describe the process very specifically. How do I configure the engine so that the paths point to the correct location of the test rule bases? Is this something that I have to do in NUnit? Or in my IDE (SharpDevelop)? Also, I know where the output folder is, but how do I reckon which Dtd or Xml files that I need to copy there? This probably exposes my inexperience, which is where you guys' expertise would be much appreciated.
Well, I figured it out--basically the unit-tests were pre-disposed to look in locations that didn't exist, and in fact bundled with the NxBRE was the pdf that defined the fields that needed to be defined for it to run.
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.