Thursday, September 02, 2004

TestFixtureSetUp and TestFixtureTearDown

MbUnit now supports TestFixtureSetUp and TestFixtuteTearDown attribute to mark methods to be executed at the beginning of a fixture test case execution and at the end.

[TestFixture]
public class Fixture
{
    [TestFixtureSetUp]
    public void TestFixtureSetUp()
    {...}

    ...

    [TestFixturteTearDown]
    public void TestFixtureTearDown()
    {...}
}
  • Both method are optional and are allowed once per class,
  • If TestFixtureSetUp invocation fails, no test case are executed and they are all marked as failures,
  • TestFixtureTearDown is always invoked,
  • If TestFixtureTearDown fails, all the test cases are marked as failure
  • TestFixtureSetUp and TestFixtureTearDown are executed on the same instance. This is not ensured for the other methods,
  • Output in those methods are recorded in the reports

AssemblyCleanUp, SetUp and TearDown

MbUnit also support test assembly setup and teardown. Those methods should be enclosed in a class that is feeded to the AssemblyCleanUpAttribute (Assembly attribute, thanks Omer), They must be public and static. The setup method must be tagged with SetUpAttribute, and the teardown method with TearDownAttribute:

[assembly: AssemblyCleanUp(typeof(AssemblyCleaner))]
...
public class AssemblyCleaner
{
    [SetUp]
    public static void SetUp()
    {
        Console.WriteLine("Setting up {0}", typeof(AssemblyCleanUp).Assembly.FullName);
    }
    [TearDown]
    public static void TearDown()
    {
        Console.WriteLine("Cleaning up {0}", typeof(AssemblyCleanUp).Assembly.FullName);
    }
}
  • Only one class with AssemblyCleanUp per assembly is authorized,
  • Both methods are optional,
  • If SetUp fails, no tests are run and they are all marked as failure,
  • TearDown is always executed.
  • If TearDown fails, all the tests are marked as failure
posted on Friday, September 03, 2004 6:20:00 AM UTC  #    Comments [20]
Tracked by:
"waterworld" (online) [Trackback]
Monday, June 06, 2005 5:35:32 PM UTC
You could always make an assembly level AssemblySetUp/AssemblyTearDown attribute couple that will not be allowed to be declared multiple times.
<br>I think the compiler will alret the user of this.
Omer van Kloeten
Monday, June 06, 2005 5:35:32 PM UTC
You are right, and the attribute would take the &quot;cleaner&quot; type.
<br>
<br>Thanks Omer :)
Jonathan de Halleux
Monday, June 06, 2005 5:35:33 PM UTC
Trey's Brain Dump
Monday, June 06, 2005 5:35:33 PM UTC
All I have to say is *wow*. You've read my mind. I posted about this need here: <a target="_new" href="http://bytemellc.com/dotText/trey/archive/2004/07/02/180.aspx">http://bytemellc.com/dotText/trey/archive/2004/07/02/180.aspx</a>
<br>
<br>Way cool dude. Thanks
Trey Hutcheson
Monday, June 06, 2005 5:35:33 PM UTC
Actually, Jamie Cansdale suggested the Assemlyb setup and tear down :) Moreover, this feature is also present in Team System.
<br>
<br>Thanks anyway :)
Jonathan de Halleux
Monday, June 06, 2005 5:35:52 PM UTC
I can't find this attribute in the current release on <a target="_new" href="http://www.dotnetwiki.org">http://www.dotnetwiki.org</a>. Is this in the 2.2 Beta?
JoeW
Monday, June 06, 2005 5:35:53 PM UTC
Nope, it is not yet in 2.20. You can find it in the .msi from the benug.package.zip from the BENUG presentation, otherwize you can wait the next release which is imminent...
Jonathan de Halleux
Monday, June 06, 2005 5:35:53 PM UTC
How imminent? :)
<br>I've just tried to switch to <a title="MbUnit, Generating Unit Testing and Model Based Testing Framework for .NET Framework" href="http://mbunit.tigris.org" target="_blank">MbUnit</a> from NUnit and this one has caught me out...
Graeme Foster
Monday, June 06, 2005 5:35:54 PM UTC
Peli's Blog
Monday, June 06, 2005 5:35:54 PM UTC
.... now!
Jonathan de Halleux
Monday, June 06, 2005 5:35:54 PM UTC
Thanks! Maybe I should try that trick on Valve... ;)
Graeme Foster
Monday, June 06, 2005 5:35:55 PM UTC
ISerializable
Monday, June 06, 2005 5:35:55 PM UTC
I'm just moving to <a title="MbUnit, Generating Unit Testing and Model Based Testing Framework for .NET Framework" href="http://mbunit.tigris.org" target="_blank">MbUnit</a> from a Nunit background. Main reason for moving was the CombinatorialTest option.
<br>To really put the icing on the cake, I'd like to &quot;loop&quot; at the fixture level. Can this frigg'ed currently?
<br>My scenario is something like this:-
<br>
<br>I have a slow operation that prepares an xml document from an input document. I'd like to run a large number of tests against the output from the slow operation (many comparing with the input document). However I have a fair few (10's) of sample input documents. I'd like the fixture to iterate over the slow operation for each file and run all of the unit tests.
<br>
<br>I currently have to iterate over the files using the Combinatorial option and put all of the tests in a single function (effectively), meaning that I can only detect the first error for each input file.
<br>
<br>Any advice to improve the process gratefully received!
<br>
<br>
Stephen Cook
Monday, June 06, 2005 5:35:56 PM UTC
Hi,
<br>
<br>You could use the TypeFixture to do that. First you define a factory class that creates the input files, second a TypeFixture class that processes the factored objects:
<br>
<br>// the factory
<br>public class SomeFactory
<br>{
<br> // tag with Factory
<br> [Factory]
<br> public XmlDocument Input1
<br> {
<br> get{...}
<br> }
<br>}
<br>
<br>// the type fixture
<br>[TypeFixture(typeof(XmlDocument)]
<br>[ProviderFactory(typeof(SomeFactory),typeof(XmlDocument)]
<br>public class TheFixture
<br>{
<br> [Test]
<br> public void ATest(XmlDocument doc)
<br> {...}
<br> [Test]
<br> public void AnotherTest(XmlDocument doc)
<br> {...}
<br>}
<br>
<br>Could that solve your problem ?
Jonathan de Halleux
Monday, June 06, 2005 5:35:56 PM UTC
This is like the example in Type-Wide Test Fixture <a target="_new" href="http://blog.dotnetwiki.org/archive/2004/04/30/179.aspx">http://blog.dotnetwiki.org/archive/2004/04/30/179.aspx</a> isn't it.
<br>
<br>Still trying to get my head around all this. Is there a doc outlining all the attributes etc. I seem to find more everywhere I look.
<br>Good stuff mind - think I'll have to become a better programmer to use it all. Is that what they mean by test-first development?
<br>
<br>If no summary doc - feed me the background info and I'll make you one! (did I really say that?)
<br>
<br>
Stephen Cook
Monday, June 06, 2005 5:35:57 PM UTC
Think I just found the info in the wiki.
<br><a target="_new" href="http://www.testdriven.net/wiki/default.aspx/MyWiki.MbUnitFeatures">http://www.testdriven.net/wiki/default.aspx/MyWiki.MbUnitFeatures</a>
Stephen Cook
Monday, June 06, 2005 5:35:57 PM UTC
But not too much info - perhaps I'll have to divvy up some input after all
Stephen Cook
Monday, June 06, 2005 5:35:58 PM UTC
Ok, still need a little help.
<br>My case requires two arguments to make it in to each test. - Input and output docs (from the slow process).
<br>Perhaps I need something like [EnumerationFixture] as they need to stay in sync (not comparing all inputs with all outputs).
<br>Can only get a single doc passed into test, even when using creating two factories. So I guess I've been found out again...
<br>
Stephen Cook
Monday, June 06, 2005 5:35:58 PM UTC
Ok - I admit, I'm a bit slow.
<br>Think I've worked this out now (not implemented yet!) TypeFixture supports (exactly) one argument, so create a new class that supports both docs as properties and pump those in...
<br>One day I'll be a programmer...
Stephen Cook
Monday, June 06, 2005 5:35:58 PM UTC
Stephen, lets move this thread to email. It's more managable.
Jonathan de Halleux
Comments are closed.