FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture & Design
Email
Print
Reprint

add to:
Del.icio.us
Digg
Google
Furl
Slashdot
Y! MyWeb
Blink
October 05, 2006

Distributed Unit Testing

(Page 4 of 5)

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"); } } }

Listing Two

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>
Listing Three
Previous Page | 1 Distributed Unit Testing | 2 Developing Automated Tests with PNUnit | 3 Synchronization Facilities | 4 Writing the Tests | 5 Conclusion Next Page
TOP 5 ARTICLES
No Top Articles.



MICROSITES
FEATURED TOPIC

ADDITIONAL TOPICS

INFO-LINK