Distributed Unit Testing

Writing the Tests

At first glance, a PNUnit test doesn't appear that different from standard NUnit tests. All the facilities available for a normal NUnit test (assertions and the like) are also available.

Listing Two presents a couple of PNUnit tests.

using System;

using NUnit.Framework;
using PNUnit.Framework;

namespace SimpleTest
{    
    [TestFixture]
    public class Test
    {
        [Test]
        public void FirstTest()
        {
            string[] testParams = 
                PNUnitServices.Get().GetTestParams();
            PNUnitServices.Get().InitBarrier("BARRIER");
            // wait two seconds
            System.Threading.Thread.Sleep(2000);
            PNUnitServices.Get().WriteLine(
                string.Format(
                    "FirstTest started with param {0}",
                    testParams[0]));
            PNUnitServices.Get().EnterBarrier("BARRIER");
        }
        public void SecondTest()
        {   
            PNUnitServices.Get().WriteLine(
                "Second test will wait for first");
            PNUnitServices.Get().InitBarrier("BARRIER");
            // will wait for the first test
            PNUnitServices.Get().EnterBarrier("BARRIER");
            PNUnitServices.Get().WriteLine(
                "First test should be started now");
        }
        
    }
}

The differences between a PNUnit and regular NUnit test involve the functionalities present in the PNUnit.Framework package. It includes a class called PNUnitServices through which the extended functionality can be accessed.

The PNUnitServices class provides methods for initializing a barrier, entering it as previously described, and retrieving the test name and test parameters. Why doesn't the test access the IPNUnitServices interface directly? Because of an implementation problem: Since the test runs on a different application domain than the PNUnitTestRunner, the interface received from the remote Runner must be made available to the running test. This is done with the CreateInstanceAndUnwrap API.

So the tests listed in Listing Two simply create a barrier, then use it to synchronize each other. The first barrier waits after initialization, making the second one wait for it in the EnterBarrier statement. With only these primitives, you can implement complex scenarios and distribute the tests over the network.

Listing Three is a typical configuration file. The script specifies both the methods where tests are implemented and the machines to execute them. Of course, the test machines must have an Agent started and listening in the correct port number—8080 by default—and the assemblies must be deployed, too.

<TestGroup>
    <ParallelTests>
        <ParallelTest>
            <Name>SimpleTest</Name>
            <Tests>
                <TestConf>
                    <Name>FirstTest</Name>
                    <Assembly>test00.dll</Assembly>
                    <TestToRun>SimpleTest.Test.FirstTest</TestToRun>
                    <Machine>localhost:8080</Machine>
                    <TestParams>
                        <string>Option1</string> 
                    </TestParams>
                </TestConf>
                <TestConf>
                    <Name>SecondTest</Name>
                    <Assembly>test00.dll</Assembly>
                    <TestToRun>SimpleTest.Test.SecondTest</TestToRun> 
                    <Machine>testbox:8080</Machine>
               </TestConf>         
          </Tests>
      </ParallelTest>
   </ParallelTests>
</TestGroup>