4

Let me explain my situation. I'm planning a kind of test case runner for doing testcases on external devices, which are microcontroller based. Lets consider the devices:

  • Device 1
  • Device 2

There exist a lot of test cases which can be run with one of the devices above. For example:

  • Testcase 1
  • Testcase 2

The main reason that all the testcases can be run with any device is, that the testcases validates some standard and this software should be extensible for future devices.

The testcases itself must be runnable with changing parameters. For example Testcase 1 does some Timing Verification the testcase needs as input parameter the datarate: 4800, 9600, 19200.

Now hoping you understand the situation, let me explain my design questions.

For implementing the test cases I thought about an Attribute based approach, like nunit does it. The more complicated problem is, how to define the parametrized testcases? Like this:

Device 1:
   Testcase 1: 
      datarate: 4800, 9600, 19200
   Testcase 2: 
      supply: 1, 2, 3

Device 2:
   Testcase 1: 
      datarate: 9600, 19200, 38400
   Testcase 2: 
      supply: 3, 4, 5

How would you design such a framework?

I've done a similar desin in python where I had for every device a XML containing the testcase definitions like:

<Testcase="Testcase 1" datarate=4800/>
<Testcase="Testcase 1" datarate=9600/>
<Testcase="Testcase 1" datarate=19200/>
1
  • 1
    only need 1 param ? I would rather have a property file per test case or some other ini – tgkprog Apr 21 '13 at 22:51
1

The method I prefer is based on a factory design pattern (which is different that most unit testing frameworks for .NET, but since you are designing your own framework starting from scratch may be ok). In this scenario each common test case is a class unto itself (based on a common TestCaseBase class) then you have a factory that generates each test case, using the constructors to set parameters.

For instance:

public interface ITestCase
{
   void Init();
   void DoTest();
   void Cleanup();
}

public class DataRateTest : ITestCase
{
   public DataRateTest (string device, int datarate1,int datarate2,int datarate3)
   {
   }
   public void Init() { }
   public void DoTest() { }
   public void Cleanup() { }
}

public class TestCaseFactory
{
  public static List<ITestCase> GetTestCaseFor(string device, string testName)
  {
     List<ITestCase> tests = new List<ITestCase>();
     switch(device+"-"+testName)
     {
         case "Device1-Test1":
              tests.Add( new DataRateTest(device,4800, 9600, 19200));
              break;

         case "Device1-Test2":
              tests.Add( SupplyTest(device,3, 4, 5));
              break;

         case "Device1-ALL":
              tests.Add( new DataRateTest(device,4800, 9600, 19200));
              tests.Add( SupplyTest(device,3, 4, 5));
              break;
     }

     if (0 == tests.Count())
        throw new NotImplementedException("No test case found for:"+device+"-"+testName);
  }
}
0

Importing and reusing shared test projects should be feasible (especially if testing common data structures, or protocols). However, more than likely and more ideally, that shared test project would test a shared production project with rather complete coverage, so there should be no need to repeat those tests.

Secondly, if behavior is essentially the same, but only varies by scaling factors, providing configuration to the test suite or fixture setup should be a reasonable option, like @tgkprog suggested. The general xUnit patterns that demonstrate and provide rationale for this are most likely the Shared Test Fixture or a Data Driven Test.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.