Test runner di test per casi di test parametrizzati

Question

Test runner di test per casi di test parametrizzati

#1 da (1 voti)
#2 da (0 voti)

4

Lascia che ti spieghi la mia situazione. Sto pianificando una specie di runner di test case per fare test su dispositivi esterni , basati su microcontrollori. Consideriamo i dispositivi:

Dispositivo 1
Dispositivo 2

Esistono molti casi di test che possono essere eseguiti con uno dei dispositivi sopra indicati. Ad esempio:

Testcase 1
Testcase 2

La ragione principale per cui tutti i test possono essere eseguiti con qualsiasi dispositivo è che i test valgono alcuni standard e questo software dovrebbe essere estensibile per i dispositivi futuri.

I testicoli stessi devono essere eseguibili con la modifica dei parametri. Ad esempio Testcase 1 esegue una verifica del tempo il testcase richiede come parametro di input datarate : 4800 , 9600 , 19200 .

Ora spero che tu capisca la situazione, lascia che ti spieghi le mie domande sul design.

Per implementare i casi di test ho pensato ad un approccio basato su Attribute , come nunit . Il problema più complicato è, come definire i test point parametrizzati? In questo modo:

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

Come progetteresti un simile framework?

Ho fatto un design simile in python dove avevo per ogni dispositivo un XML contenente le definizioni di testcase come:

<Testcase="Testcase 1" datarate=4800/>
<Testcase="Testcase 1" datarate=9600/>
<Testcase="Testcase 1" datarate=19200/>

unit-testing design c#

posta Razer 21.04.2013 - 18:35

fonte

2 risposte

Leggi altre domande sui tag unit-testing design c#

Quando si utilizza MVVM, si dovrebbero creare nuovi modelli di visualizzazione o sostituire i modelli? caching su più server

score 1 · Answer 1

Il metodo che preferisco è basato su un schema di progettazione di fabbrica (che è diverso dalla maggior parte dei framework di test unitari per .NET , ma dal momento che stai progettando il tuo framework partendo da zero potrebbe essere ok). In questo scenario, ogni caso di test comune è di per sé una classe (basata su una classe TestCaseBase comune), quindi esiste una factory che genera ciascun caso di test, utilizzando i costruttori per impostare i parametri.

Ad esempio:

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

score 0 · Answer 2

L'importazione e il riutilizzo di progetti di test condivisi dovrebbero essere fattibili (specialmente se si testano strutture dati o protocolli comuni). Tuttavia, più che probabile e più idealmente, quel progetto di test condiviso testerebbe un progetto di produzione condiviso con una copertura piuttosto completa, quindi non ci dovrebbe essere alcuna necessità di ripetere quei test.

In secondo luogo, se il comportamento è essenzialmente lo stesso, ma varia solo in base ai fattori di ridimensionamento, fornire la configurazione alla suite di test o all'impostazione della fixture dovrebbe essere un'opzione ragionevole, come suggerito da @tgkprog. I pattern generali xUnit che dimostrano e forniscono motivazioni per questo sono più probabilmente il Shared Test Fixture o un Test guidato dai dati .