Wie mache ich einen UnitTest?

[Nico1999]

hi ich habe mal versucht einen UnitTest in Eclipse zu machen zu folgender Methode

public class Figur{
    public boolean isFigurWhite(){
        return this.farbe==Farbe.WHITE;
    }
}

und das was dann rausgekommen is wo ich das TestFile gemacht habe ist

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class FeldIsFigurWhite {

    @Test
    void test() {
        fail("Not yet implemented");
    }

}

allerdings ist da jetzt alles unterstrichen also wie macht man das den jetzt?

 

[sascha-sphw]

Hast Du junit als dependency hinzugefügt?

 

[Robert Zenz]

Auszerdem muessen die Test-Methoden public sein, glaube ich.

 

[httpdigest]

Auszerdem muessen die Test-Methoden public sein, glaube ich.

Seit JUnit 5 nicht mehr.

 

[Nico1999]

Hast Du junit als dependency hinzugefügt?

wo mach ich das?

 

[Jw456]

wenn du in Eclipse bist soltte das schon vorhanden sein.
gehe links auf dein Package dann rechts Klick und "JUnit Test Case" auswählen

 

[Nico1999]

sry aber funktiert immer noch nicht

import static org.junit.jupiter.api.Assertions.*;
// wenn ich hier die imports machen will die morpheus gemacht hat verschwinden die einfach wieder
class FeldTest {

    @Test
    void testIsFigurWhite() {
        assertEquals//das ist immernoch unterstrichen und ich hab keine ahnung warum            
    }
}

 

[Neumi5694]

Und in den Tips steht das "warum" normalerweise.
So wie's steht, kanns auch nicht funktionieren. Du wirst der Methode schon ein paar Parameter mitgeben müssen.

Assertions (JUnit 5.10.2 API)

declaration: module: org.junit.jupiter.api, package: org.junit.jupiter.api, class: Assertions

junit.org

Die Klasse wird ja gefunden, sonst würden sich Compiler oder IDE schon beim Import aufregen.
Probier mal, die Klasse zu importieren und nicht deren statische Methoden und dann Assertions.assertEquals aufzurufen.

 

[Jw456]

import static org.junit.jupiter.api.Assertions.*;

Ist das richtig ?

ich würde sagen

import static org.junit.Assert.*;

wenn du "jupiter.api" benuzt wirst du das auch in den "dependency" hinzugefügen müssen

 

[thecain]

Ich wüsste nicht, warum er JUnit 4 verwenden sollte. jupiter isch schon richtig und @Neumi5694 hat ja auch diese Dependency verlinkt

 

[Nico1999]

testet man auch die getter und setter und konstruktoren oder is das unnötig oder kann man das Automatisch machen lassen

 

[thecain]

Durch das Testen der "businesslogik" sollte. Die Getter und Komstruktoren mitgetestet werden. Wenn nicht, scheinen sie überflüssig zu sein.

 

[Nico1999]

wie kann man den private Methoden testen ?
oder muss man die dann fürs Testen einfach public machen ?

 

[thecain]

Ersetze "Getter und Konstruktoren" meiner vorderen Antwort durch private Methoden und du hast die Antwort

 

[KonradN]

Oft ist eine private Methode ein Zeichen, dass du die Klassen nicht gut 'geschnitten' hast. Du scheinst ein Verhalten in der Klasse zu implementieren, das nicht in die Klasse gehört und daher intern ist. Das kann also in eine eigene Klasse gehören.

Wenn du Dir etwas Komplexes ansiehst, wie z.B. ein Auto. Du hast von außen nur etwas wie Blinker rechts ein als Interface.
Intern macht das Auto dann etwas wie Lampen an und aus zu schalten. Das könnte man in einer private Methode haben. Aber das ist ein Verhalten nicht vom Auto. Statt dessen hast du ein Steuergerät, dass dies macht. Auto hat also ein Steuergerät. Das Steuergerät hat aber genau dieses Verhalten nach außen und du kannst es testen. War das an der Stelle erst einmal anschaulich?

Um ein Gefühl zu bekommen macht es als Übung auf jeden Fall Sinn, sich TDD anzusehen. Test Driven Development schreibt immer zuerst Tests und so kann man gar nicht in das Problem kommen, dass man ein Verhalten hat, dass nicht getestet wurde. Dazu gibt es hier im Forum (mindestens) zwei Beispiele: FizzBizz und ein Graphen Beispiel. Aber generell ist die Empfehlung wohl das Buch von Kent Beck: Test Driven Development by example.

Und eine Möglichkeit kann es ggf auch geben: package private - dann haben nur Klassen im gleichen Package Zugriff. Bricht aber die Kapselung. Daher so wie @thecain: Die Methoden wurden entweder mitgetestet oder man sollte da ein Refactoring machen.

Edit: Typos, die ich jetzt am Rechner sehe.

 

[KonradN]

Da ich ein Beispiel für ein mögliches Refactoring gegeben habe, möchte ich auch ein Gegenbeispiel nennen:
Private Methoden entstehen sehr oft auch durch Refactorings. Das Refactoring für doppelten Code muss man nur anschauen:
Du schreibst eine doppelt verkettete Liste. Das Listenelement ist eine innere Klasse. Und Du hast eine Methode, um ein Element vor ein vorhandenes Element hinzu zu fügen:
- Du gehst bis zu dem Element vor dem eingefügt werden soll.
- Du fügst vor dem Element ein

Nun kommt die Methode, die nach einem vorhandenen Element einfügt:
- Du gehst bis zu dem Element, nach dem eingefügt werden soll.
- Du fügst nach dem Element ein.

==> Suchen eines Elementes ist damit doppelt und das kommt in eine eigene Methode. Diese ist natürlich spezifisch für die Liste. Da kann man (aus meiner Sicht jetzt) keine neue Klasse entwerfen, die dies dann als Verhalten bekommen kann.

Das also nur kurz zum Aufzeigen, dass das oben genannte also nichts ist, wo man mit der Brechstange ansetzen muss um dann dass Buch 1001 Nacht Klassen zu schreiben.

 

[M.L.]

private Methoden testen

Zusätzlich (Quelle: Besser Coden (2018), Seite 246): (Screenshot als Anhang)