I am aware that the current release of PEX allows use with the NUnit framework.
The thing is I can't configure it to use the NUnit framework.
In the Options -> PEX: What Exactly do i have to put in the "TestFramework" and "TestFrameworkDirectory".
I Have tried many combinations but failed to achieve any success.
I've went to the DevLabs forum in search for a solution, I've got a solution to the problem.
Here it is:
http://social.msdn.microsoft.com/Forums/en-US/pex/thread/5f7cc37d-0b8e-4bad-af6f-c53c5076e7c2
You have to set the "TestFramework" option to "NUnit" (without quotes) and the "TestFrameworkDirectory" option to the directory where the nunit.framework.dll file is located (if you used the .msi installer it's probably "%ProgramFiles%\NUnit x.y.z\bin\net-2.0\framework").
Related
I am currently using NUnit in Visual Studio to execute my Selenium tests. What I want is some good reporting and I found ReportUnit.
What I cannot seem to figure out is where NUnit places the test result xml files on my machine. I am no tech-wiz so I am struggling to find out how to get ReportUnit working. I found the documentation here: http://relevantcodes.com/reportunit/
But cannot quite figure out how to get my test result files in a specific folder and then open them with ReportUnit.
Any help is appreciated.
Kind regards,
Anand
Use the --out option of nunit3-console.exe to specify where the result file should go. e.g.
nunit3-console.exe MyTests.dll --out=C:/TestResult.xml
(TeamCity version 7.1.3 on Windows 2008 R2, using Octopack NuGet package 2.0.20 for Console applications.)
Having some weird issues here: Rather than repeat the entire thread, I was hoping I could get some takers reading my linked post (short) and maybe offer some insight.
Basic issue is stated in the title of this post.
http://help.octopusdeploy.com/discussions/problems/6435-octopackpackageversion-variable-not-usedpicked-up-in-teamcity
I have been trying to determine why in just one particular project within the same solution why it is that the OctoPackPackageVersion variable is not being passed to nuget via Octopack whereas all other projects in the solution behave as they should picking up the proper version from the TeamCity system variable defined as:
...nuget\NuGet.exe" pack "bin\Release\NuGet-temp\CaptiveAire.Core.SocketServers.ServiceHost.nuspec" -OutputDirectory "bin\Release" -basePath "bin\Release\NuGet-temp" -Version "1.0.0.0" -NoPackageAnalysis
Thanks for any assistance.
Ok so this came down to having mixed versions of OctoPack support files: targets and newer C# targets DLL for msbuild.
See the linked support page in the original question.
Hope this possibly helps someone else.
I've been trying to use ILMerge to merge assemblies in VS2010 and the resulting primary assembly ends up being unusable. This only seems to occur when the assemblies being merged contain methods with Lambda expressions. Also, it seems to work fine in VS2008.
I've outlined my investigation in more detail here.
Any insight into how to solve this would be greatly appreciated.
There have been recent updates to ILMerge to fix several VS2010 compatibility problems. And there's a new command line option to target .NET 4.0. Download the latest and greatest.
Mike Barnett responded via email and informed me the problem might be in my config file somewhere. His suggestion was to use the /targetplatform option:
Ex.
ILMerge.exe /targetplatform:v4,c:\Windows\Microsoft.NET\Framework\v4.0.30319 /out:foo.exe Program.exe MathLib.dll
I added the /targetplatform and path, removed the ILMerge config file and now everything works fine.
I installed the latest binaries from
http://xunitcontrib.codeplex.com/releases/view/35006
and followed the suggestions from
http://xunitcontrib.codeplex.com/Thread/View.aspx?ThreadId=79225
because the linked installation instructions are out of date (basically there are more libs to copy to the plugins dir)
Now my resharper shows the plugin in the Plugins diialog, but I have no testing functionality at all. Not even Testdriven.NET seems to recognize the xunit tests (even if I "reinstalled" them via the xunit.installer.exe).
What a drag! Anyone can give me a hand here?
--Jan
A I guess, I just forgot one of the dlls.
Now I have got it working.
Is there an API for running Visual Studio Unit Tests programmatically?
Running MSTests.exe with Process.Start() does not work in the current scenario. What I'm looking for is something like the NUnit SimpleTestRunner.
Any ideas?
/Erik
You're correct in that there's no public API for the mstest framework. I wrote a manual replacement for mstest one day to see how hard it was, and it's not as simple as it looks (particularly if you want to take advantage of more than one CPU core), so beware of going down this path.
Personally I've always just run mstest.exe programatically and then parsed the resulting .trx XML file. Are there any particular reasons why you can't use Process.Start to run it?
P.S. Some of the strange behaviour of mstest.exe are solved if you pass the /noisolation command line parameter - give that a go if you feel so inclined :-)
Update: Erik mentions he wants to run the test API in the current thread so he can set the thread culture for globalization issues.
If you run a unit test under the debugger, you'll notice that mstest creates a bunch of threads, and runs all your tests in different threads, so this isn't likely to work even if you could access the API.
What I'd suggest doing is this:
From your test "runner" application, set an environment variable
Run mstest pointing it at the specific tests
Add a [ClassInitialize] (or [TestInitialize]) method which reads this environment variable and sets the culture
Profit!
After taking a deep dive with reflector into MSTest.exe and further down into the Visual Studio Unit Test stack, I found that the API used by MSTest is sealed up and made private so that i cannot be used from the outside.
Why not using Reflector and seeing how NUnit SimpleTestRunner is running the tests... And then use this technique...
You can make use of the Microsoft REST API's for TFS to run ms tests. Please refer to the documentation here.
I've linked to "Call a Rest API" so that you can see how you'd go about calling one of the REST API's for TFS.
Note that if your tests are linked to the build, they should run automatically every time a build is queued.
Here is the link to Run Functional Tests.
I've also discovered an article on using the TFS SDK API to run tests. Here is that link as well: Link to API Article