I did some research and I always found that the tests are located in some dll. However in my project there are no .dlls created and the tests are located in the .exe file.
Do I have to set some specific parameters?
This is the log from vsts after I pointed the path for test assemblies to the exe. Before I pointed it to **\*.test*.dll but it could never find any tests. When running the tests or build locally there is also never a test dll created.
2017-08-15T08:55:15.1386003Z Starting test execution, please wait...
2017-08-15T08:55:15.4276084Z Information: NUnit Adapter 3.8.0.0: Test execution started
2017-08-15T08:55:15.4276084Z
2017-08-15T08:55:15.4276084Z Information: Running all tests in d:\a\1\s\Workshop\Workshop\bin\Release\Workshop.exe
2017-08-15T08:55:15.4286085Z
2017-08-15T08:55:16.8199687Z Information: NUnit3TestExecutor converted 1 of 1 NUnit test cases
2017-08-15T08:55:16.8199687Z
2017-08-15T08:55:16.9559755Z Information: NUnit Adapter 3.8.0.0: Test execution complete
2017-08-15T08:55:16.9559755Z
2017-08-15T08:55:17.2181003Z Passed TwoIntegers_Add_Sum
How do I make the tests show up as .dlls instead of being inside the .exe?
As your example shows, NUnit as well as VS Test Explorer are very happy to have tests in an .exe along with the production code. Most people prefer to have the tests separate from the production code, which is distributed to users, so they create a separate project to contain them.
So, your answer is that there is no way to make the tests "show up" as a .dll if they are actually in the .exe. OTOH, assuming you are the developer of the application, you can create a separate project, which creates a class library, and move the tests into that project.
Related
I have a TeamCity build configuration that builds a C# project, runs some unit tests, and then does some extra things. My question is: Can I get information about my unit test run stored into build configuration variables (i.e. how many tests were run, how many were successful, how many failed, how many were skipped) so that I can then check these variables in a PowerShell script in later build steps and perform different actions depending on how many tests have passed?
AFAIK the best way is to ask these information directly to teamcity server using its REST API (pay attention, maybe the build locator could be a little be tricly to be found, if the build is still running).
By other hand, you can parse your NUnit test result file (or files if you run more than one NUnit test runner step in your build) inside your build agent machine.
I'm using VS 2013 and NUnit.
I'm running my tests in Resharpers's TestRunner GUI - this thing:
I have multiple projects (Solution.Foo, Solution.Bar, etc), and tests for each project in Solution.Foo.Tests, Solution.Bar.Tests, etc.
One of my tests in Foo.Tests is accessing a file, located in the Solution.Foo.Tests Folder.
I use TestContext.CurrentContext.TestDirectory to locate it and when I run that test it all works just fine.
If I run the whole suite of tests in Foo.Tests, (i.e. click on Solution.Foo.Tests in the Runner GUI and run) then it's fine.
But if I select one test from Bar.Tests and my file-reading test from Foo.Tests, then it fails, because suddenly TestDirectory is set to a path in Bar.Tests.
It's as if NUnit set TestDirectory once when it starts running a collection of tests, determined by where the first test is and then never updates it again.
Any ideas what's going on and how to fix it?
ReSharper has an optimisation for speed, by sharing an AppDomain across multiple assemblies. The downside to this is that it will pick an arbitrary assembly to be the main one, which means the directory can be wrong (and it might not pick up the correct app.config, too).
You can disable the optimisation in ReSharper → Options → Unit Testing, by checking the "Use separate AppDomain for each assembly with tests".
Is it possible to run NCover automatically from code instead of running NCover manually or via command line?
Here is the scenario, I have written a few tests, I execute all the tests and after the tests are completed, NCover should run automatically for that particular test project and store the coverage report as an XML in a location.
Is this possible to do? Kindly help.
Running NCover from the command line was the only option with NC3. When we updated NC4 the default works like this --> you create a project, the NCover service watches for a process to start that meets the match rules defined in the project, and then collects coverage on it.
This doc may be of some help: http://www.ncover.com/support/docs/desktop/user-guide/coverage_scenarios/how_do_i_collect_data_from_nunit
If you have more questions, please reach out to us at support#ncover.com.
I'm playing around with Microsoft Test Manager 2013 (though it appears it is just MTM2012) to try and get a better understanding of test cases and test suites as I want to use this at work. So I was hoping that I could run a test suite on a build which gets included in this test suite. That is what I WANT to do, but it could very well be wrong. So maybe a better scope of what I'm doing at work might lend to a better answer.
My company makes tablet PC's. I write programs for those tablets. For sake of argument lets just say there are 5 tablets, that run a similar array of OS's. Tablet1,2,3 and 4 can run WinXP, WinXP embedded, Win7, and Win7 Embeded, and Tablet5 can run Win7, Win7 Embedded, and Win8 embedded. Lets say i'm making a Display test program. Naturally this display test will run differently on each tablet, but the program it self is supposed to be able to handle that along with not being able to worry about OS. So I wrote out a very simple test. Open Program, try to open again, verify only 1 instance, check display, close program.
I figured it would be good to make a Test Suite called "Complete Display Program Test" and put 5 sub test suites to that for each tablet. Then moved the 5 test cases to a single test suite. I configured all test cases to only have the correct tablet/OS configuration. Queued a build and waited for it to finish. I then attached that build to the main test suite. I then clicked on run a test for tablet 1 but I didn't see the build attached to the test runner. I've looked around a little bit to see why or how and haven't found anything. Question is is how do I do that? Or if you are scratching your head and wondering why in the world I am doing it this way then by all means suggest another way. This is the second time I have ever looked into MTM so I might not be doing it right.
Thank you for your time.
When running manual tests from MTM you will not see the build you are using in Test Runner.
But if you complete the test and set the test outcome you will be able to check which build you've ran the test against.
Just double-click on the test or select "View Results" to display test results:
This column is not visible by default. You will have to right-click on the column row and select the column "Buld number" to be displayed.
You will also be able to see the build number in "Analyse Test Runs" area:
The things are slightly different if you are running automated test.
Consider following approach:
Automate your Test Cases
See How to: Associate an Automated Test with a Test Case for details.
Create a Build Definition building your application under test AND assemblies containing your tests.
I strongly recommend build application you want to test and test assemblies using in the same Build Definition. (You will see why a little bit later).
Run this build definition and deploy the latest version of the application to the environment where you want run the tests.
This is very important to understand: if you run automated tests the tests assemblies only would be deployed automatically to the environment.
It's your job to deploy the right version of the application you are going to test.
Now you can run tests from MTM.
You can do it the way described by #AndrewClear in the comment to this answer: "choose "Run with Options" when you're beginning a test run" and select the latest build.
Now test assemblies containing tests which are using to automate Test Cases will be deployed automatically to the test environment and the tests will be executed.
That is the point you should recognize why is it so important to build application and tests with a single Build Definition: since the build number you've just selected when starting the tests will be stored along with the test results on TFS you will later know what version of you application you were testing (assuming you deployed the right version, of course).
You could go a little bit further if you want even more automation (This is the way I'm currently running automated tests)
Use Deploy-Build-Test template (this is a good place to start reading about Setting Up Automated Build-Deploy-Test Workflows).
Using this approach you will be able to automate deployment of the application you want to test.
I have 13 separate but related architecture assemblies, and 13 separate NUnit test assemblies, each one containing all the test fixtures for its matching architecture assembly. I am using NUnit 2.5.2 (latest version currently).
I can run each test assembly separately in the NUnit GUI and all the tests pass. However, when I come to combine them into a single NUnit project file, NUnit insists on applying a single config file to the whole test run. This won't work because each test assembly requires different config. I can't merge them into one "uber-config" file because some of the sections are mutually exclusive. I have tried running each assembly in the project in separate AppDomains, and also separate processes, but in both cases it fails to use the DLL-specific config file, so all the tests crash and burn.
I have done a Google search but so far I have not found any indication that NUnit supports this scenario. Am I right, or have I missed something?
I have tried my hardest to re-architecture the tests so that they could share the same config file, but I've had to admit defeat on that front.
NUnit 2.5 has as setting where you can enable each assembly to run in a separate AppDomain. By doing this, NUnit will load the config for the assembly and not the one for the .nunit project.
For more info, see here:
http://nunit.org/index.php?p=settingsDialog&r=2.5
In the past I've done this with a batch file running each assembly through the nunit console independently. At one point I had something that merged the xml output together. It might be in the CruiseControl.Net code.
I haven't worked on the NUnit project for a while. I only have the older code in my head. But the issue is that you get one config per AppDomain and NUnit loads all the test assemblies into one AppDomain.
You might want to try alternate runners such as Resharper or TestDriven.net