Testowanie implementacji wielu interfejsów z tymi samymi testami - JUnit4

Question

Chcę uruchomić te same testy JUnit dla różnych implementacji interfejsu. Znalazłem ładne rozwiązanie z opcji @Parameter:

public class InterfaceTest{ 

    MyInterface interface; 

    public InterfaceTest(MyInterface interface) { 
    this.interface = interface; 
    } 

    @Parameters 
    public static Collection<Object[]> getParameters() 
    { 
    return Arrays.asList(new Object[][] { 
     { new GoodInterfaceImpl() }, 
     { new AnotherInterfaceImpl() } 
    }); 
    } 
} 

Ten test będzie prowadzony dwukrotnie, najpierw z GoodInterfaceImpl następnie z AnotherInterfaceImpl klasie. Ale problem polega na tym, że większość testcases potrzebuje nowego obiektu. Uproszczony przykład:

@Test 
public void isEmptyTest(){ 
    assertTrue(interface.isEmpty()); 
} 

@Test 
public void insertTest(){ 
    interface.insert(new Object()); 
    assertFalse(interface.isEmpty()); 
} 

Jeśli isEmptyTest prowadzony jest po insertTest zawiedzie.

Czy istnieje opcja automatycznego uruchamiania każdej wersji testowej z nową instancją implementacji?

BTW: Wdrożenie clear() lub reset() -method dla interfejsu nie jest tak naprawdę opcje ponieważ nie musiałby go w kodzie produkcyjnym.

Answer 1

Utwórz interfejs fabryczny i implementacje, prawdopodobnie tylko w hierarchii testów, jeśli nie potrzebujesz czegoś takiego w produkcji, i zwróć listę fabryk na numer getParameters().

Następnie można wywołać fabrykę w metodzie adnotowanej @Before, aby uzyskać nową instancję testowanej klasy dla każdego uruchomienia metody testowej.

Answer 2

Oto inne podejście do wzorca Template Method:

Testy interfejsu zorientowanych iść do klasy bazowej:

public abstract class MyInterfaceTest { 

    private MyInterface myInterface; 

    protected abstract MyInterface makeContractSubject(); 

    @Before 
    public void setUp() { 
     myInterface = makeContractSubject(); 
    } 

    @Test 
    public void isEmptyTest(){ 
     assertTrue(myInterface.isEmpty()); 
    } 

    @Test 
    public void insertTest(){ 
     myInterface.insert(new Object()); 
     assertFalse(myInterface.isEmpty()); 
    } 
} 

Dla każdej klasy betonu, należy zdefiniować konkretną klasę testową:

public class GoodInterfaceImplTest extends MyInterfaceTest { 

    @Override 
    protected MyInterface makeContractSubject() { 
     // initialize new GoodInterfaceImpl 
     // insert proper stubs 
     return ...; 
    } 

    @Test 
    public void additionalImplementationSpecificStuff() { 
     ... 
    } 
} 

Niewielka przewaga nad @Parameter polega na tym, że dostajesz nazwę konkretnej klasy testowej zgłaszanej, gdy test się nie powiedzie, więc od razu wiesz, która implementacja się nie powiodła.

Przy okazji, aby to podejście w ogóle działało, interfejs musi być zaprojektowany w sposób umożliwiający testowanie wyłącznie za pomocą metod interfejsu. Oznacza to testowanie oparte na stanie - nie można weryfikować prób w podstawowej klasie testowej. Jeśli musisz zweryfikować makiety w testach specyficznych dla implementacji, testy te muszą przejść do konkretnych klas testowych.

Answer 3

wszelki wypadek ktoś osiąga tutaj (jak ja), patrząc na testowanie wielu implementacji tego samego interfejsu w .NET można zobaczyć jedną z metod, które używałem w jednym z projektów here

Poniżej jest to, co śledzimy w skrócie:

Ta sama dll projektu testowego jest uruchamiana dwukrotnie przy użyciu vstest.console, poprzez ustawienie zmiennej środowiskowej. Wewnątrz testu (w inicjalizacji zespołu lub inicjalizacji testu) zarejestruj odpowiednie implementacje w kontenerze IoC, w oparciu o wartość zmiennej środowiskowej.

Answer 4

W JUnit 5 można zrobić:

@ParameterizedTest 
@MethodSource("myInterfaceProvider") 
void test(MyInterface myInterface) {} 

static Stream<MyInterface> myInterfaceProvider() { 
    return Stream.of(new ImplA(), new ImplB()); 
} 

interface MyInterface {} 

static class ImplA implements MyInterface {} 

static class ImplB implements MyInterface {}