Unit test

[Melina]

Guten morgen, 

ist es möglich über Junit auch Eingaben zu testen, also system.in zu testen? Sodass Eingaben automatisch passieren ? 

[Whiz-zarD]

Nein. Wozu auch? Unit Tests sind keine interaktiven Benutzertests, sondern automatisierte Tests, die im Idealfall nach jedem Buildprozess durchlaufen werden. Du gibst also die Eingaben per Programmcode vor. So ist auch sichergestellt, dass das Ergebnis immer reproduzierbar ist, da immer die selben Eingaben gemacht werden.

Du musst also die Eingabe von deiner zu testenden Einheit trennen, sodass die Einheit auch ohne Interaktivität des Benutzers durchlaufen werden kann.

[thereisnospace]

vor 4 Stunden schrieb Melina:

Guten morgen, 

ist es möglich über Junit auch Eingaben zu testen, also system.in zu testen? Sodass Eingaben automatisch passieren ? 

Natürlich geht das. Beispiel:

Wir haben eine Login-Maske wie man sie kennt:

Eingabefeld: Benutzername

Eingabefeld: Passwort

Button: Login

Beim Klick des Buttons Login werden die eingegebenen Strings von den Eingabefeldern einer Methode übergeben, beispielsweise benutzerEinloggen(string pw, string user). Dieser Methode gibst du ja die Parameter aus den Eingabefeld mit.

Um im Unittest die Benutzereingabe zu testen, rufst Du einfach im Unittest die Methode benutzerEinloggen(string pw, string user) auf und gibst dann entweder hardgecodedete Strings mit oder Variablen aus der Unit Test Klasse.

Somit simulierst Du dann eine Benutzereingabe und den Klick auf den Login Button.

[Whiz-zarD]

vor 7 Minuten schrieb thereisnospace:

Um im Unittest die Benutzereingabe zu testen, rufst Du einfach im Unittest die Methode benutzerEinloggen(string pw, string user) auf und gibst dann entweder hardgecodedete Strings mit oder Variablen aus der Unit Test Klasse.

Somit simulierst Du dann eine Benutzereingabe und den Klick auf den Login Button.

Das ist nichts anderes, als das, was ich geschrieben habe.

Benutzereingaben während eines Unit Test-Laufes machen keinen Sinn. Man möchte doch nicht ständig bei jedem Lauf Benutzername und Passwort eintippen.

[Melina]

Ich glaube ich meinte das ähnlich. Ich wollte einen Unit Test machen womit eingaben automatisch gemacht werden können ob die eingaben auch so sind wie erwartet. einfach um zu wissen Spiel läuft noch nichts kaputt gemacht, statt ständig alles von hand einzugeben

[maestro impostor]

In .NET kann man bei den UnitTests via Annotations mehrere zu testenden Werte an den Test übergeben. Heißt der Test wird mit allen per Annotation angegeben werten getestet. 

Wenn du das Verhalten deiner Oberfläche bei bestimmten Eingaben Testen willst empfehle ich Selenium. Lässt sich sehr gut via Python umsetzten. Ansonsten auch per Java / .NET. Ich Persönlich bevorzuge da aber Python. 

Leider geht aus deiner Antwort nicht ganz klar hervor was du nun gerne umsetzen möchtest. 

[thereisnospace]

vor 20 Stunden schrieb Whiz-zarD:

Das ist nichts anderes, als das, was ich geschrieben habe.

Benutzereingaben während eines Unit Test-Laufes machen keinen Sinn. Man möchte doch nicht ständig bei jedem Lauf Benutzername und Passwort eintippen.

Ich weiß. Ich habe es nur nochmal anfängerfreundlich näher erläutert

Bearbeitet 9. Oktober 2019 von thereisnospace

[allesweg]

vor 20 Stunden schrieb Melina:

Ich glaube ich meinte das ähnlich.

Wenn du nur glaubst, etwas gemeint zu haben: wer soll es wissen?

vor 20 Stunden schrieb Melina:

Ich wollte einen Unit Test machen womit eingaben automatisch gemacht werden können ob die eingaben auch so sind wie erwartet.

Die sind nicht nur wie erwartet sondern genau so, wie im Testfall gespeichert.

[TheGuy]

Am 8.10.2019 um 12:56 schrieb thereisnospace:

Natürlich geht das. Beispiel:

Wir haben eine Login-Maske wie man sie kennt:

Eingabefeld: Benutzername

Eingabefeld: Passwort

Button: Login

Beim Klick des Buttons Login werden die eingegebenen Strings von den Eingabefeldern einer Methode übergeben, beispielsweise benutzerEinloggen(string pw, string user). Dieser Methode gibst du ja die Parameter aus den Eingabefeld mit.

Um im Unittest die Benutzereingabe zu testen, rufst Du einfach im Unittest die Methode benutzerEinloggen(string pw, string user) auf und gibst dann entweder hardgecodedete Strings mit oder Variablen aus der Unit Test Klasse.

Somit simulierst Du dann eine Benutzereingabe und den Klick auf den Login Button.

Das ist falsch. Unit Tests sollen Verhalten von Methoden überprüfen. Was du beschreibst ist eine einfache Parameterübergabe ala set/get was üblicherweise nicht mit Tests abgedeckt wird. Verhalten wäre in diesem Zusammenhang eine Überprüfung der Parameter auf Formate ect

[maestro impostor]

vor 20 Stunden schrieb TheGuy:

Das ist falsch. Unit Tests sollen Verhalten von Methoden überprüfen. Was du beschreibst ist eine einfache Parameterübergabe ala set/get was üblicherweise nicht mit Tests abgedeckt wird. Verhalten wäre in diesem Zusammenhang eine Überprüfung der Parameter auf Formate ect

Öhm... das ist doch genau das, was er beschreibt:

Er will die Methode

public ILoginResult benutzerEinlogen(string password, string userName)  { // implementation }

testen.

Das macht er mit einem UnitTest.
Er gibt Werte für die Übergabeparameter password und userName vor, ruft damit die zu testende Methode auf und prüft ob die Methode das tut, was sie soll.

Verstehe gerade deinen Einwand nicht.
Wenn innerhalb der Methode noch eine weitere Methode aufgerufen wird mit den Parametern, bspw:

private IVerifyResult verifyParameter (...something) { // implementation }

lässt sich über ArgumentCaptor überprüfen, ob die korrekten Werte an verifyParameter übergeben worden sind.

Bearbeitet 10. Oktober 2019 von r4phi

[thereisnospace]

Am 9.10.2019 um 15:28 schrieb TheGuy:

Das ist falsch. Unit Tests sollen Verhalten von Methoden überprüfen.

Genau das habe ich beschrieben.

Setter und getter überprüfen keine Login Methode. Sie setzen, beziehungsweise holen sich Werte aus einem Objekt. Das hat nichts mit meinem Beitrag zu tun.

Ich habe nur beschrieben wie er das Login Verhalten via Unittests ohne manuelle Nutzereingaben überprüfen kann.

Danke an @r4phi für die Ergänzung.

Bearbeitet 11. Oktober 2019 von thereisnospace