If you have read my editorial for very long, you won’t be surprised to find that I am a strong proponent of Testing; especially automated testing. While reading up on the XUnit project found on GitHub, I came across a blog by James Newkirk, one of the major XUnit qw2contributors, sharing why he dropped the [Setup] and [Teardown] decorations from XUnit, which he had originally put into NUnit when porting it from Junit. You can read his reasoning from his blog here.
For those of you who haven’t done a lot of unit testing, let me give you some background on Setup and Teardown. Those decorations allowed you to create a method in your test class that would be called during test execution. Setup is called before the execution of each test. Teardown is called after the execution of each test. Using these methods allowed you to reset the foundation before each test was executed, especially when using class level properties instead of variables created inside of a test method.
James didn’t like the Setup and Teardown because the complete code executed for each test was spread out across the class. In order to understand what was happening you had to look at three different methods. The second thing he didn’t like was that you had to implement Setup and Teardown for every possible test need. So, by removing this capability, it required developers to be more intentional for their shared methods. You also do not have to know the magic behavior of the method decorations to implement Setup and Teardown. You can still have a private method that may be used to setup or teardown. But, you have to implicitly call it from each test requiring it. So, the capability is still available. You simply have to implement it differently, and the intention is clear.
James recommends not sharing variables. You may have a setup method to instantiate a variable, but each test has its own instance of that variable. In this case there is not teardown method required, because the variable goes out of scope.
There is also a decoration for test classes that work on the entire class. That is Fixture Setup and Fixture Teardown. A method decorated with those attributes are called once when the class is instantiated (Setup), and when the class is disposed (Teardown). Those decorations have also been removed from XUnit, with a preference given instead to normal Dot Net coding practices. If you want to have code executed when the class is created, put it in the Constructor, or call it from the Constructor. This is how we do it in all our other code. Why be different here. The same goes for Fixture Teardown. If you need to do some work when the class is disposed, implement the IDisposable interface, and place your teardown code in the Dispose() method, or make a call to your method from Dispose().
I find this mindset interesting, and intend to look further into XUnit. They have done a good job, it seems, making it integrate with existing testing implementations. More on that later.
Cheers,
Ben