È possibile implementare una serie di test riutilizzabili per verificare l'implementazione di un'interfaccia?

Question

Sto scrivendo una serie di classi di raccolta in C#, ognuna delle quali implementa interfacce personalizzate simili. È possibile scrivere una singola raccolta di test unitari per un'interfaccia e eseguirli automaticamente tutti su diverse implementazioni? Vorrei evitare qualsiasi codice di test duplicato per ogni implementazione.

Sono disposto a esaminare qualsiasi estensione di framework (NUnit, ecc.) O Visual Studio per ottenere ciò.

---

Per coloro che cercano di fare lo stesso, ho postato la mia soluzione concreta, in base al largo di avandeursen's accepted solution, come an answer.

Answer 1

Sì, è possibile. Il trucco è lasciare che la tua gerarchia di test della classe di unità segua la gerarchia di classi del tuo codice.

Supponiamo di avere un'interfaccia Itf con classi di implementazione C1 e C2.

Per prima cosa creare una classe di test per Itf (ItfTest). Per eseguire effettivamente il test, è necessario creare un'implementazione fittizia dell'interfaccia Itf.

Tutti i test in questo ItfTest devono passare a qualsiasi implementazione di Itf (!). In caso contrario, l'implementazione non è conforme alla Liskov Substitution Principle (la "L" nel film di Martin SOLID principi di progettazione OO)

Così, per creare un banco di prova per C1, la classe C1Test può estendere ItfTest. La tua estensione dovrebbe sostituire la creazione dell'oggetto fittizio con la creazione di un oggetto C1 (inserendolo o utilizzando uno GoF factory method). In questo modo, tutti i casi ItfTest vengono applicati alle istanze di tipo C1. Inoltre, la tua classe C1Test può contenere casi di test aggiuntivi specifici per C1.

Allo stesso modo per C2. E puoi ripetere il trucco per classi e interfacce nidificate più profonde.

Riferimenti: Binder Polymorphic Server Test modello, e PACT di McGregor - Architettura parallela per prova di componenti.

Answer 2

Per eseguire questa operazione è possibile utilizzare gli attributi [RowTest] in MBUnit. L'esempio seguente mostra dove si passa il metodo di una stringa per indicare quale classe di implementazione di interfaccia che si desidera creare un'istanza, e quindi crea questa classe attraverso la riflessione:

[RowTest] 
[Row("Class1")] 
[Row("Class2")] 
[Row("Class3")] 
public void TestMethod(string type) 
{ 
    IMyInterface foo = Activator.CreateInstance(Type.GetType(type)) as IMyInterface; 

    //Do tests on foo: 
} 

Nel [Row] attributi, è possibile passare qualsiasi numero arbitrario dei parametri di input, come i valori di input per i test oi valori attesi da restituire mediante invocazioni di metodi. Sarà necessario aggiungere argomenti dei tipi corrispondenti come argomenti di input del metodo di prova.

Answer 3

Espansione alla risposta Joe's, è possibile utilizzare l'attributo [TestCaseSource] in NUnit in modo simile a Rowest di MBUnit. È possibile creare una fonte di test case con i nomi delle classi in là. È quindi possibile decorare ogni test quale attributo TestCaseSource. Quindi utilizza Activator.CreateInstance che puoi trasmettere all'interfaccia e verrai impostato.

Qualcosa di simile (nota - testa compilato)

string[] MyClassNameList = { "Class1", "Class2" }; 

[TestCaseSource(MyClassNameList)] 
public void Test1(string className) 
{ 
    var instance = Activator.CreateInstance(Type.FromName(className)) as IMyInterface; 

    ... 
} 

Answer 4

Questa è la mia concreta attuazione in base al largo di avandeursen's answer:

[TestClass] 
public abstract class IMyInterfaceTests 
{ 
    protected abstract IMyInterface CreateInstance(); 

    [TestMethod] 
    public void SomeTest() 
    { 
     IMyInterface instance = CreateInstance(); 
     // Run the test 
    } 
} 

Ogni implementazione di interfaccia definisce quindi la seguente classe di test:

[TestClass] 
public class MyImplementationTests : IMyInterfaceTests 
{ 
    protected override IMyInterface CreateInstance() 
    { 
     return new MyImplementation(); 
    } 
} 

SomeTest viene eseguito una volta per ogni calcestruzzo TestClass derivato da IMyInterfaceTests. Usando una classe base astratta, evito la necessità di eventuali implementazioni fittizie. Assicurati di aggiungere TestClassAttribute a entrambe le classi o questo non funzionerà. Infine, è possibile aggiungere eventuali test specifici dell'implementazione (come i costruttori) alla classe figlia, se lo si desidera.