Introducing PetaTest - A Tiny Unit Testing Framework
Sunday, 31 July 2011
In the spirit of PetaPoco, PetaTest is a tiny, embeddable, self-contained, dependency free unit testing framework for .NET and Mono.
As a long time user of NUnit I've been generally very happy with it however during development I tend to find it a bit cumbersome:
- I've always found the startup and shutdown time of the GUI runner to be painfully slow. During development I find these few seconds of delay extremely annoying - especially when trying to just cancel a run and get back to the IDE.
- I've never found an easy way in NUnit to run just a single test. Often during development and especially while debugging you have a specific test case that you want to run and everything else to be ignored. I've tried NUnit's category support but it didn't agree with me.
- I've always wished NUnit could give a source code extract of where an assertion failed. Sure it gives a stack trace but that's not quite the same as something pointing straight at a line of code.
To be fair I should probably have looked a little harder at NUnit as I'm sure has there are solutions to these problems. However I had another problem I wanted to solve - the ability to embed the testing framework and produce completely self contained unit test modules that don't require any external dependencies or test runners.
So PetaTest is a self contained single .cs file that runs a set of unit tests. It's very fast, supports running just a single test by marking it with an attribute and gives source code extracts when assertions fail. It writes to console output while running the tests and also generates a HTML report for a more graphical, click to expand view of the results. (see example)
I've been using PetaTest for about a month now and find I'm consistently more productive with it than I was with NUnit. I've updated PetaPoco's unit tests to use it - and I'm using it in a number of other projects too.
You can find out more about PetaTest on the project page.
8 Comments
Leave a comment
You are my hero.
Nice! I was actually considering changing over to NUnit from MSTest so that all our unit tests in the future could be ported to run on Mono, but I think I will give this tool a shot. The one thing I love about MSTest is the ability to run or debug any test (or group of tests) with a single hot key. Not being able to figure out an easy way to do that with NUnit has been driving me nuts!
I quite like the solution you came up with, so I will give it a shot.
Is the code for using PetaTest with PetaPoco in Github? I have downloaded and am looking at PetaPoco 4.0.3, so I assume I just need to get the trunk code from Github?
Why not VisualStudio testing?
@Kendall: PetaPoco includes the PetaTest.cs file but PetaTest also has it's own github repository - linked to from the PetaTest project page.
@Michael: I probably should have looked at VisualStudio testing a little closer but will that let me run the tests under Mono?
I use CodeRush unit test runner which runs in the IDE. Resharper has one as well. Running single tests out of Visual Studio is a ridiculous time saver. Normally there are commands to run tests under cursor, tests in the class under cursor, all tests in a namespace, solution etc. Perhaps what you really want is a Visual Studio plugin that could run mstest/nunit/mbunit tests by invoking an appropriate (installed) test runner.
Hey Igor, perhaps but I also need the tests to run under Mono, sometimes on a GUI less Linux box and the startup/shutdown time of some of these other runners is still a killer for me. With PetaTest running tests for this JavaScript compiler I'm working on I can hit run, see 110+ tests pass, press enter and be back in the IDE in less than 1 second.
I agree it's not perfect as I need to fudge the code to switch active tests, but I tend to do that fairly rarely anyway.
@Michael I am pretty sure the Visual Studio tests won't run on Mono?
@Brad, I think we need a way to ensure that when you are debugging and an Assert fails, that the exception will look like it was thrown from the line where the Assert was called, which is what MS Test does. I think they use the DebugAttribute(ignore) or something to have it show up in the debugger at the original caller line of code.
@Brad, if you use:
[System.Diagnostics.DebuggerStepThroughAttribute()]
to decorate the Assert functions, then the exception looks like it was thrown directly by the calling code. Works nicely.