Scrittura di un test unitario per implementazioni multiple di un'interfaccia

Question

Ho un'interfaccia List le cui implementazioni includono Elenco collegato singolarmente, Doubly, Circular ecc. I test di unità che ho scritto per Singly dovrebbero fare del bene per la maggior parte di Doubly nonché Circular e qualsiasi altra nuova implementazione dell'interfaccia. Quindi, invece di ripetere i test unitari per ogni implementazione, JUnit offre qualcosa di integrato che mi permetterebbe di avere un test JUnit ed eseguirlo contro diverse implementazioni?

Utilizzo di test parametrici JUnit Sono in grado di fornire diverse implementazioni come Singly, doublely, circular ecc. Ma per ogni implementazione lo stesso oggetto viene utilizzato per eseguire tutti i test della classe.

Answer 1

Con JUnit 4.0+ è possibile utilizzare parameterized tests:

• Aggiungi @RunWith(value = Parameterized.class) annotazione al vostro dispositivo di prova
• Creare un metodo public static ritorno Collection, annotare con @Parameters, e mettere SinglyLinkedList.class, DoublyLinkedList.class, CircularList.class, ecc in quella collezione
• Aggiungere un costruttore al dispositivo di prova che prende Class: public MyListTest(Class cl) e memorizzare Class in un'istanza variabile listClass
• Nel metodo setUp o @Before, utilizzare List testList = (List)listClass.newInstance();

Con l'impostazione sopra al suo posto, il corridore parametrizzato farà una nuova istanza del dispositivo di prova MyListTest per ogni sottoclasse che fornite nel metodo @Parameters, che consente di esercitare la stessa logica di test per ogni sottoclasse da testare.

Answer 2

avrei probabilmente evitare i test con parametri di JUnit (che secondo me sono piuttosto maldestramente attuato), e solo fare un abstract List classe di test che potrebbe essere ereditato da prove implementazioni:

public abstract class ListTestBase<T extends List> { 

    private T instance; 

    protected abstract T createInstance(); 

    @Before 
    public void setUp() { 
     instance = createInstance(); 
    } 

    @Test 
    public void testOneThing(){ /* ... */ } 

    @Test 
    public void testAnotherThing(){ /* ... */ } 

} 

Le diverse implementazioni quindi ottenere la loro proprie classi concrete:

class SinglyLinkedListTest extends ListTestBase<SinglyLinkedList> { 

    @Override 
    protected SinglyLinkedList createInstance(){ 
     return new SinglyLinkedList(); 
    } 

} 

class DoublyLinkedListTest extends ListTestBase<DoublyLinkedList> { 

    @Override 
    protected DoublyLinkedList createInstance(){ 
     return new DoublyLinkedList(); 
    } 

} 

La cosa bella di fare in questo modo (invece di fare una classe di test che verifica tutte le implementazioni) è che se ci sono alcuni casi angolo specifici che desideri prova con una implementazione, puoi semplicemente aggiungere più test alla sottoclasse test specifica.

Answer 3

È possibile creare un metodo di supporto nella classe di test che imposta il test List in modo che un'istanza di una delle implementazioni dipenda da un argomento. In combinazione con this dovresti essere in grado di ottenere il comportamento desiderato.

Answer 4

Espansione sulla prima risposta, gli aspetti Parametri di JUnit4 funzionano molto bene. Ecco il codice effettivo che ho usato in un test di un progetto. La classe viene creata utilizzando una funzione di fabbrica (getPluginIO) e la funzione getPluginsNamed ottiene tutte le classi PluginInfo con il nome utilizzando SezPoz e le annotazioni per consentire il rilevamento automatico di nuove classi.

@RunWith(value=Parameterized.class) 
public class FilterTests { 
@Parameters 
public static Collection<PluginInfo[]> getPlugins() { 
    List<PluginInfo> possibleClasses=PluginManager.getPluginsNamed("Filter"); 
    return wrapCollection(possibleClasses); 
} 
final protected PluginInfo pluginId; 
final IOPlugin CFilter; 
public FilterTests(final PluginInfo pluginToUse) { 
    System.out.println("Using Plugin:"+pluginToUse); 
    pluginId=pluginToUse; // save plugin settings 
    CFilter=PluginManager.getPluginIO(pluginId); // create an instance using the factory 
} 
//.... the tests to run 

Nota è importante (io personalmente non hanno alcuna idea perché funziona in questo modo) per avere la collezione come un insieme di array di parametro attuale alimentato al costruttore, in questo caso una classe chiamata PluginInfo. La funzione statica wrapCollection esegue questa attività.

/** 
* Wrap a collection into a collection of arrays which is useful for parameterization in junit testing 
* @param inCollection input collection 
* @return wrapped collection 
*/ 
public static <T> Collection<T[]> wrapCollection(Collection<T> inCollection) { 
    final List<T[]> out=new ArrayList<T[]>(); 
    for(T curObj : inCollection) { 
     T[] arr = (T[])new Object[1]; 
     arr[0]=curObj; 
     out.add(arr); 
    } 
    return out; 
} 

Answer 5

Sulla base del anwser di @dasblinkenlight e this anwser mi si avvicinò con un'implementazione per il mio caso d'uso che mi piacerebbe condividere.

Uso lo ServiceProviderPattern (difference API and SPI) per le classi che implementano l'interfaccia IImporterService. Se viene sviluppata una nuova implementazione dell'interfaccia, è necessario modificare solo un file di configurazione in META-INF/services/ per registrare l'implementazione.

Il file in META-INF/services/ prende il nome il nome completo della classe dell'interfaccia di servizio (IImporterService), ad esempio,

de.myapp.importer.IImporterService

Questo file contiene una lista di casses che implementano IImporterService, per esempio

de.myapp.importer.impl.OfficeOpenXMLImporter

La classe factory ImporterFactory fornisce ai clienti implementazioni concrete dell'interfaccia.

---

Le ImporterFactory restituisce un elenco di tutte le implementazioni dell'interfaccia, registrati attraverso il ServiceProviderPattern. Il metodo setUp() garantisce che venga utilizzata una nuova istanza per ogni caso di test.

@RunWith(Parameterized.class) 
public class IImporterServiceTest { 
    public IImporterService service; 

    public IImporterServiceTest(IImporterService service) { 
     this.service = service; 
    } 

    @Parameters 
    public static List<IImporterService> instancesToTest() { 
     return ImporterFactory.INSTANCE.getImplementations(); 
    } 

    @Before 
    public void setUp() throws Exception { 
     this.service = this.service.getClass().newInstance(); 
    } 

    @Test 
    public void testRead() { 
    } 
} 

Il metodo ImporterFactory.INSTANCE.getImplementations() è simile al seguente:

public List<IImporterService> getImplementations() { 
    return (List<IImporterService>) GenericServiceLoader.INSTANCE.locateAll(IImporterService.class); 
} 

Answer 6

So che questo è vecchio, ma ho imparato a fare questo in una variante leggermente diversa, che funziona bene in cui è possibile applicare la @Parameter ad un membro del campo per iniettare i valori.

È solo un po 'più pulito a mio parere.

@RunWith(Parameterized.class) 
public class MyTest{ 

    private ThingToTest subject; 

    @Parameter 
    public Class clazz; 

    @Parameters(name = "{index}: Impl Class: {0}") 
    public static Collection classes(){ 
     List<Object[]> implementations = new ArrayList<>(); 
     implementations.add(new Object[]{ImplementationOne.class}); 
     implementations.add(new Object[]{ImplementationTwo.class}); 

     return implementations; 
    } 

    @Before 
    public void setUp() throws Exception { 
     subject = (ThingToTest) clazz.getConstructor().newInstance(); 
    }