| 

.NET C# Java Javascript Exception

1
Wenn ich eine Klasse testen will, mache ich für jede Klasse, eine Testklasse.
Jetzt wollte ich die eine Klasse mit einem Parametertest testen.das klappt soweit auch...
wunderbare sache. JEdoch habe ich noch ein Test der Klasse, der nicht mit den Parametern zu tun hat.
Wen ich das als normale Test methode hinzufüge, wird er für jeden Parameter ausgeführt, obwohl die da nicht mal benutzt werden..

Kann ich den Test irgenwie sagen, das er das igrnorieren soll?
ODer muss ich jetzt zwei test klassen für die eine Klasse implementieren?
ein parametertest und ein normalen junit test?

hoffe war verständlich erklärt...wenn nciht gebe ich auch noch ein beispiel.
Danke im Vorraus
26.02.2014
tanzverfuehrung 147 8
3 Antworten
0
Wenn ich dein Problem richtig verstanden habe suchst du nach Mocks. Damit kannst du Dummies von Klassen automatisch erzeugen.

siehe: mockito
26.02.2014
Floyd 14,6k 3 9
ne sorry das meinte ich nicht
tanzverfuehrung 26.02.2014
0
wen es interessiert....hier ist auch meine frage noch mal besser formuliert

Lösung
26.02.2014
tanzverfuehrung 147 8
0
Theoretisch könntest du auch weitere manuelle Tests einfügen in diese Klasse, aber das Problem wird eher die Performance der Tests sein, du willst ja deine Tests schnell ausgeführt haben und die Tests sollen möglichst nicht einfach brechen.

Bei gerade einmal zwei Tests (drei mit Badpath) frage ich mich eher ob das Sinn macht hier einen Parameterized Test zu erstellen. Besser drei Testmethoden mit sprechenden Namen finde ich:

@Test
public void testCommandIsEnabledTrue() throws Exception {
command.setEnabled(true);
assertThat(command.isEnabled(), is(true));
}

@Test
public void testCommandIsEnabledFalse() throws Exception {
command.setEnabled(false);
assertThat(command.isEnabled(), is(false));
}

@Test
public void testCommandIsEnabledThrowsException() throws Exception {
try {

command.setEnabled(null); // ich gehe davon aus das es hier eine Exception
// gibt sonst einfach entsprechend versuchen
// eine zu werfen
fail("Eine Exception wurde hier erwartet");
} catch (Exception e) {
assertThat(e instanceof Exception, is(true)); // Exceptionklasse die
// geworfen wird
assertThat(e.getMessage(), is("mein Text")); // Exception Text der
// erwartet wird
}
}


Wie du genau den Status festsetzt musst du wissen, soll nur ein Beispiel sein. Selbst für meine GUI Editoren mache ich keine Parameterized Tests mehr. Es ist zwar redundant das ganze immer wieder zu schreiben, aber jemand anders versteht eigentlich sehr schnell deinen Test und das ist wichtiger.

Vorteil ist einfach das deine Userstory alleine schon mit dem Methodennamen klar erkennbar ist. Dein Parameterized Test ist schwieriger zu lesen für einen dritten oder du musst viel Kommentieren. Kommentare sind aber oft nicht gepflegt, das musste ich in der Arbeit sehr oft schon feststellen. Nicht nur im Programmcode, auch in den Tests die Sinnvolle Namen hatten wie test1, test2, test3....

Fällt nun der Test testCommandIsEnabledTrue() auf die Nase, muss man nicht viel Zeit zum lesen und verstehen der Parameterized Klasse investieren. Jemand kann gleich rauslesen was hier passiert mit 3 Zeilen Code. Ausserdem brechen deine Tests nicht so schnell wie in den Parameterized Tests, leider eigene Erfahrung.

Für Berechnungen von komplexeren Sachen nutzen wir die Parameterized Tests noch, in der Kategorie SlowTests da die 20 Tests 50 Sekunden Laufzeit haben. Hier macht es eben Sinn, wird aber nur in der Nacht ausgeführt.

Nur meine Meinung :)
19.03.2014
Lord_Pinhead 778 8

Stelle deine Parameter-Frage jetzt!