Test-Methoden schreiben

[LucaToni]

public double flaecheninhaltDreieck(double g, double h)
{
        return g * h / 2;
    }

Wie kann ich zu dieser Methode eine Testmethode schreiben?

Ich verstehe den Sinn davon nicht ganz von Testmethoden... Das kann man ja einfach überprüfen ohne jetzt eine Methode dafür zu schreiben.

 

[httpdigest]

Du testest diese Methode mit ein paar (ausgedachten) Werten für g und h und prüfst, ob auch das erwartete Ergebnis zurückkommt. Betrachte die Methode einfach als Blackbox, von der du die Implementierung nicht kennst.

 

[Kirby.exe]

public static void main(String[] args){
    System.out.println(flaecheninhaltDreieck(2.0,4.0));
}

 

[LucaToni]

   public void flaecheninhaltDreieckTest()
    {
    Formelsammlung f1=new Formelsammlung();
    assertEquals(180.5,f1.flaecheninhaltDreieck(19.0,19.0),0.001);
    }

TEST ERFOLGREICH

Was bringt mir das jetzt aber?

😀

 

[Dimax]

das bringt nichts wen du alles richtig eingibst versuch aber sowas

 assertEquals(180,f1.flaecheninhaltDreieck(19.A,-19.0),0.001*0/2);

 

[LucaToni]

das bringt nichts wen du alles richtig eingibst versuch aber sowas

assertEquals(180,f1.flaecheninhaltDreieck(19.A,-19.0),0.001*0/2);

Ja, da wird Test nicht erfolgreich sein... aber.... DAS WEISS MAN DOCH VORHER...Warum schreibt man für sowas eine Testmethode?
Könntet Ihr mir ein Beispiel geben wo man es nicht vorher weiß und eine Testmethode schreiben muss..
Ich muss ja das Ergebnis einer Berechnung kennen, bzw den Rechenweg, damit ich das beurteilen kann... ansonsten kann ich ja nicht wissen, dass die Methode zum Beispiel hier zwei Parameter erwartet... und mit einem Parameter funktioniert die Methode nicht...

 

[httpdigest]

Man schreibt Tests, um Regression (etwas, was früher einmal funktioniert hat, funktioniert jetzt nicht mehr) zu vermeiden. Wenn also jemand auf die Idee kommt, die Methode flaecheninhaltDreieck() anzupassen, zu optimieren oder sonstwie zu ändern, und dabei einen Fehler macht, dann finden Tests solche Fehler.
Das Ganze bringt dir etwas, wenn du über einen längeren Zeitraum an einer Library bzw. einem Projekt arbeitest. Da passieren immer mal hier und da Anpassungen und man möchte sich vor Fehlern durch solche Anpassungen schützen.

 

[M.L.]

Ich verstehe den Sinn davon nicht ganz von Testmethoden...

Stichwort TDD (Test Driven Development): erst den Testcode schreiben, im Positivfall dann den Produktivcode. Und wenn man mehr als nur einen Parameter testen will, kann man JUnit i.V. mit parametrisierten Tests verwenden: https://www.baeldung.com/parameterized-tests-junit-5

 

[LucaToni]

Man schreibt Tests, um Regression (etwas, was früher einmal funktioniert hat, funktioniert jetzt nicht mehr) zu vermeiden. Wenn also jemand auf die Idee kommt, die Methode flaecheninhaltDreieck() anzupassen, zu optimieren oder sonstwie zu ändern, und dabei einen Fehler macht, dann finden Tests solche Fehler.
Das Ganze bringt dir etwas, wenn du über einen längeren Zeitraum an einer Library bzw. einem Projekt arbeitest. Da passieren immer mal hier und da Anpassungen und man möchte sich vor Fehlern durch solche Anpassungen schützen.

Die Antwort macht die Sache schon schlüssiger für mich. DANKE schonmal dafür.

 

[LucaToni]

Stichwort TDD (Test Driven Development): erst den Testcode schreiben, im Positivfall dann den Produktivcode. Und wenn man mehr als nur einen Parameter testen will, kann man JUnit i.V. mit parametrisierten Tests verwenden: https://www.baeldung.com/parameterized-tests-junit-5

DANKE für die Quelle. schaue ich mir an.

 

[LimDul]

Ein weiterer Vorteil ist, man deckt leichter Flüchtigkeitsfehler auf. Hatte ich erst heute in Code von mir.

Eingabe eine Adresse, die dann durch einen externen Service auf korrektheit geprüft werden soll.
Wenn ich also im UI irgendein Feld der Adresse ändere, muss die Adresse als "Ungeprüft" markiert werden.
Das hatte ich beim schreiben bei fast allen Felder auch gemacht - nur beim Ort hatte ich es vergessen. Als ich die Tests geschrieben habe, ist das dann sofort aufgefallen. Und die ganzen Konstellationen testest man im UI nicht in der Gründlichkeit durch, wie man Testfälle schreibt.

Mit Testfällen kann man auch viel viel schneller verschiedene Konstellationen abdecken. Was ist z.B. bei deiner Methode mit negativen Höhen/Grundflächen? Was ist wenn Höhe oder Grundfläche 0 ist?

Wenn ich Unit-Tests schreibe, lege ich immer viel Wert auf Eingabeparameter die nicht offensichtlich richtig sind. Das heißt, was ist wenn man null bergibt? Was ist wenn bei bei Zahlen negative Werte oder 0 übergibt? Was ist wenn man bei Strings einen Leerstring übergibt? Man stellt so oft beim Test schreiben fest, dass man in der Entwicklung ein paar Sonderkonstellationen übersehen hat.

Das Ziel sollte nicht sein eine Testmethode für eine Methode zu schreiben - sondern viele Testmethoden für unterschiedliche Konstellationen.

 

[LucaToni]

Ein weiterer Vorteil ist, man deckt leichter Flüchtigkeitsfehler auf. Hatte ich erst heute in Code von mir.

Eingabe eine Adresse, die dann durch einen externen Service auf korrektheit geprüft werden soll.
Wenn ich also im UI irgendein Feld der Adresse ändere, muss die Adresse als "Ungeprüft" markiert werden.
Das hatte ich beim schreiben bei fast allen Felder auch gemacht - nur beim Ort hatte ich es vergessen. Als ich die Tests geschrieben habe, ist das dann sofort aufgefallen. Und die ganzen Konstellationen testest man im UI nicht in der Gründlichkeit durch, wie man Testfälle schreibt.

Mit Testfällen kann man auch viel viel schneller verschiedene Konstellationen abdecken. Was ist z.B. bei deiner Methode mit negativen Höhen/Grundflächen? Was ist wenn Höhe oder Grundfläche 0 ist?

Wenn ich Unit-Tests schreibe, lege ich immer viel Wert auf Eingabeparameter die nicht offensichtlich richtig sind. Das heißt, was ist wenn man null bergibt? Was ist wenn bei bei Zahlen negative Werte oder 0 übergibt? Was ist wenn man bei Strings einen Leerstring übergibt? Man stellt so oft beim Test schreiben fest, dass man in der Entwicklung ein paar Sonderkonstellationen übersehen hat.

Das Ziel sollte nicht sein eine Testmethode für eine Methode zu schreiben - sondern viele Testmethoden für unterschiedliche Konstellationen.

Dann kann man doch aber für alles Mögliche unendlich viele Testmethoden schreiben... ist das Sinn der Sache?

 

[LimDul]

Nein, nicht unendlich viele - aber sinnvoll viele. Man muss über die Eingabeparameter sinnvolle Äquivalenzklassen bilden. Das kann bei Zahlen oft sein: Eine Kleiner 0, 0, eine größer 0. ggf. noch INT_MAX/INT_MIN dazu, sofern sinnvoll.

Bei Strings ist es oft null, Leerstring, gefüllter String, etc. Es ist oft so, dass die Testklassen mehr Code haben als der eigentliche Code, das ist aber vollkommen in Ordnung.

 

[mihe7]

Dann kann man doch aber für alles Mögliche unendlich viele Testmethoden schreiben... ist das Sinn der Sache?

Nein, Tests sind keine Korrektheitsbeweise. Die erste Frage ist ja schon einmal, welchen Zweck der Test erfüllen soll.

Während mit im Nachhinein geschriebener Tests in erster Linie die Einhaltung der Anforderungen getestet wird, verfolgt das TDD m. E. das Ziel, ein besseres Design zu erzielen.

Grundsätzlich werden aber immer nur bestimmte Aspekte getestet, was die Auswahl der Testdaten und -fälle entsprechend einschränkt. Beispielsweise wäre im Fall der Flächenberechnung eines Dreiecks kein Fehlverhalten zwischen den Eingabewerten 2, 3 sowie 20, 30 zu erwarten, da man sich in der gleichen Größenordnung bewegt. Anders sieht es aus, wenn Du große Werte oder welche verwendest, die sehr nah an 0 sind. Da kann es schnell mal zu Überläufen oder nicht hinnehmbaren Ungenauigkeiten kommen. Ähnliches gilt für 0 und negative Werte. Alles Dinge, wo man sich Probleme vorstellen könnte.

Noch eine Warnung: fang nicht an, Tests für konkrete Implementierungen zu schreiben, sondern für das Verhalten. Ansonsten bekommst Du Abhängigkeiten zum Code, die Dich beim Entwickeln nur behindern.