"Local Mock Variables" — Ein dritter eleganter Weg in JMockit?

2. Mock-Deklaration als Method Parameter

Sehr komfortabel können Mock-Deklaration auch direkt als Methoden-Parameter angegeben werden (Zeile 8):

[java highlight=“8″]
public final class MyTest
{
final IUser user = …
final IPassword password = …

// usual test code …
@Test
public void login_should_accept( @Mocked final IDatabase mockedDatabase )
{
// …
final boolean loginStatus = mockedDatabase.login( user, password );
// and so on …

assertThat( loginStatus ).isTrue();
}
}
[/java]

Die mockedDatabase wird hier individuell nur für die Testmethode login_should_accept instantiiert. Einen Konflikt, wie in zuvor genannter Einschätzung beschrieben, gibt es hier nicht. „Test Isolation“ bleibt gewahrt.

Auch die 2. Deklarations-Art ist grundsätzlich empfehlenswert.

Allerdings gibt es hier ein ganz anderes Dilemma:
setzt man beispielsweise den „Mercedes der xUnit“-Frameworks ein, also TestNG 😉 [3], und nutzt hier einen komfortablen @DataProvider, der ebenfalls Methoden-Parameter – hier für das Hineinreichen von Testdaten an eine Testmethode – nutzt, kollidiert dies mit den gemockten Methoden-Parametern. TestNG und das JMockit-Framework „kennen“ sich nicht. TestNG lässt (derzeit) keinen Mix der Methoden-Parameter mit 3rd Party Frameworks zu (die @NoInjection-Annotation von TestNG hat eine andere Aufgabe).

Wie kann man nun für eine Testmethode sowohl vorteilhaft einen TestNG-DataProvider als auch individuelle Mocks anbieten ?

Ein eleganter Ansatz könnte sein …