NUnit
Microsoft Team System NUnit Adapter
We’ve prepared a free, open source adapter for NUnit designed to allow you to run Team System tests with NUnit, including nunit-console. This will let you inter-operate with source including Team System unit tests, as well as integrate Team System unit tests into your automated builds and scripts by literally running Team System tests under the NUnit framework.
This is provided as source making an NUnit addin. Place this addin in the appropriate folder depending on where you have NUnit installed, instructions on NUnit addin and extensibility are at http://www.nunit.com/index.php?p=nunitAddins&r=2.4.6.
This same addin is used within TestMatrix to provide the ability to run Team System unit tests, but we’re also providing it free to NUnit users of all kinds. TestMatrix is not required to use this addin. Source is also provided under the same license terms as NUnit itself, so that you can modify or work with this code as you see fit.
Inside the adapter, we’ve implemented a NUnit ’suite builder’, which is really the transformation logic that takes a compiled assembly and extracts the classes and methods that form unit tests. Along with basic unit testing, we’ve a simple, though working data driven test attribute along with a TestContext as used by Team System. This essentially allows you to open a table via ADO.NET and have the test execute once per row.
We’ve not big Team System test users ourselves, preferring NUnit, so this has more of an NUnit ‘feel’, adapting the Team System tests to fit in NUnit. Feedback, particularly on differences in semantics will be appreciated!
You can download it http://www.exactmagic.com/products/mstest/actions/download.html.
| Permalink | Comments[2] |
MS Team System Test Support
New on experimental updates, build 2277 and higher is support for MS Team System unit tests. Now TestMatrix supports NUnit, csUnit, MbUnit, and MSTS all in one runner.
This support is actually provided as a plug in to NUnit, which we’ll be making as a free open source component once we finish testing.
| Permalink | Comments[0] |
NUnit 2.4.6 Support
Fresh build this morning on Experimental updates, NUnit 2.4.6 is supported in releases 2237 and higher.
| Permalink | Comments[0] |
Orcas Test Support
Looking forward to future versions, we’re looking at bridging the gap to provide NUnit, MBUnit, Selenium, and maybe CSUnit testing support inside of the Team System Test framework. I’m assuming folks will start moving to the official MS test solution as Orcas rolls out, which leaves you in a pickle. What do you do with all your NUnit tests? Convert them? It seems like a lot of work, and possibly error prone, and what about third party components that you use that have integrated tests, or multiple project teams on multiple schedules?
So, that leaves me with the following theory – it’s better to integrate into what will be the omnipresent MS Test solution by making plug-ins that will run all your existing tests as-is, without modification, so that you can mix and match the best test tool for the job, yet have all the results merge together into one collected test output provided by the Orcas test system.
- Mark the failure line in the editor
- Bridge Integration
- NUnit
- MBUnit
- CSUnit
- Selenium
- Allow ‘Debug Tests’ from the context menu in the editor
- Provide a Test Statistics panel with Pass/Fail/Inconclusive ratios and charts
-
Custom Test Types
- Repeating / Timed
- ‘With Coverage’
- ‘With Performance’
What do you think?
| Permalink | Comments[3] |
NUnit Integrated
TestMatrix is all about making NUnit easier and faster to use while you are programming. It’s most useful if you are already using NUnit for testing, and are looking for a faster way to run your tests, gather coverage, and debug you tests without shuffling through a lot of windows or external tools by giving you direct feedback in the editor about your test cases. It’s a free trial to download, give it a shot and it’ll save you time testing.
We’ve got
- NUnit 2.4
- Code Coverage, Memory, and Performance Profiling
- Fully 64 bit support (better than NCover!)
From your test cases, just right click and run. The menu even shows you which test, whether you are in a [TestFixture] or a [TestCase].
Right there, in the editor the test result is marked with a colored indicator (which you can pick the colors)
And most convenient, when you have a failed test the failure and root cause is show to you right there in the editor with the ‘fingers’ test failure marker and a tooltip.
And, we’ve got NUnit GUI style test ‘tree’ as a docking window.
| Permalink | Comments[0] |
More than One Way to Test it
Sometimes when I’m testing, I just want to smoke test the entire solution, particularly when I just synched up multiple changes from the rest of the team. This is when I use the TestMatrix | Test Explorer, then pick the solution in the drop down.
From here I can just hit the play arrows and run the entire solution. See the icon for solution, and the
nested assembly icon? I can click and explore the tests visually like I would with NUnit GUI but one notch more convenient by avoiding the window shuffle toggling back and forth.
I also tend to work in one assembly/project at a time with modular changes. This is where selecting a single project makes sense. The drop down is filtered to be only those projects that reference NUnit to keep it nice and short. So in exploring and running the tests I can work on the solution or a single project.
If I’m just working in a single class, doing pure TDD unit testing as I code, I tend to run the tests right from the editor with the context menu or Ctrl-R,T as a hotkey (remember it as Control Run Test).
And having run the test, the test results show up right there in the editor.
I think about it in terms of big test runs and small test runs. Big runs I tend to do with the explorer, mainly having been hooked on NUnit GUI early on. Small runs I tend to do right in the editor, similar to TestDriven.NET – but with graphical feedback right on the test case. Pass/Fail is a bit more ‘in your face’. Particularly on failed tests, which is what it’s all about. Just hover over the ‘fingers’ – the 5 horizontal markers. This shows you exactly where a test failed, and prints out the message and stack trace. You can see why your test failed without a lot of hopping around.
| Permalink | Comments[1] |
