If test fixtures could be private



Last one for the day, then I go home.


 


You’ve read Test Methods are neither Methods nor Tests.  You’ve dried off & are fully recovered.


 


This is the practical reason why NUnit should remove the ‘public’ requirements from test fixtures.  I didn’t include it in the last post, because I didn’t want people to focus on the concrete impacts of my reasoning.


 


Today, NUnit sets you up to write like this:


 



   class MyClass


   {


      //…


   }


 


   //————


   // may be same file, different file in the same project, different netmodule, different assembly


 


   [TestClass]


   public class MyClassTests


   {


      [TestMethod]


      public void Test1()


      {


         //…


      }


   }


 


I prefer to write like this:


 



   class MyClass


   {


      //…


 


      [TestClass]


      /*public*/ class Tests


      {


         [TestMethod]


         /*public*/ void Test1()


         {


            //…


         }


      }


   }


 


It lets me normalize my naming.  Tests for MyClass are called “MyClass.Tests”. 


 


A Rename Refactoring of MyClass to YourClass, I won’t miss MyClassTests from the first example, because I’ve removed that duplication from my code.


 


BTW, I’m 0x1E today.  Instead of taking the day off, I decided to spend the day doing only work I enjoy.  Hence 8 full-featured blogs in one day.

Comments (2)

  1. Here here on normalized naming!

    Here here to co-location of tests!

    Happy birthday!

  2. Darren Oakey says:

    Jay – I agree..

    I’ve always put test classes inside the parent class. It’s one of the ongoing fights with another architect here. I understand the argument that your normal assemblies don’t need to reference your test assemblies – but the advantages are so huge – otherwise you need an identical test hierarchy to your code hierarchy, you lose track of things etc etc etc

    I always have the following:

    > class blah

    > {

    > #region Tests

    > [TestFixture]

    > private class BlahTests

    > {…}

    > #endregion

    > #region Support functions for others testing this

    > public class Testing

    > {

    > public Blah CreateTestBlah(); {…}

    > public Blah CreateTestBlahWithSomeCharacteristic(); {…}

    > public void DeleteTestBlah( Blah testBlah);

    > }

    > #endregion

    > … class body …

    > }

    This way, if someone is looking at the class, they always have the test class available. This is good because:

    – if it’s maintained, the tests are visible and tend to get added to / updated

    – the test hierarchy can build up with the class hierarchy

    – the tests serve as examples of how to use the class

    Also, the CreateTestBlah methods on Testing mean that people up the line don’t have to worry about setting up things. You want to test doing reimbursements against a vehicle package? You call VehiclePackage.Testing.CreateTestLivePackage – you then just issue a reimbursement – makes all the tests clean and simple.

    To pull it off, I have my own TestEverything function which just gathers up all the testFixtures, test methods and runs them :)