Run während der Entwicklung

[White_Fox]

Mahlzeit allerseits.

Folgendes: In meinem Programm tut sich jetzt schon das ein oder andere und momentan starte ich es häufig aus der IDE heraus. Mittlerweile hab ich aber das "Problem", immer wieder erst umständlich viele Handgriffe zu benötigen um z.B. Daten zu erzeugen, mit denen ich neue Funktionen ausprobiere.
Diese Handgriffe nerven allmählich.

Jetzt könnte ich in meiner main-Methode eine Stelle einbauen, die Daten vorlädt. Häßlich dabei: Ich müßte einige Testklassen, die nicht zum Programm gehören, zu den src-Dateien hinzufügen. Das will ich aber nicht, Testkram gehört nicht in den Sourcecode.

Ich würde auch einen Launcher bei den Testdateien erstellen, komme da aber (soweit ich das bisher probiert habe) nicht mehr mit dem Run-Befehl ran.

Im Launcher ein paar Zeilen einbauen und diese später auskommentieren...bäh, nö.

Frage: Wie macht ihr das?

PS: Ich arbeite mit Netbeans.

 

[Robat]

Was spricht dagegen Testklassen zu schreiben? Dort definierst du die Daten einmalig und brauchst die Tests nur immer wieder neu ausführen. Abhängigkeiten kannst du ggf. über ein Framework (wie Mockito) mocken.

 

[kneitzel]

Also was startest Du denn genau? Ich fürchte, ich habe das noch nicht richtig verstanden.

Was ich mache:

a) Vor allem habe ich Unit-Tests. Diese lasse ich während der Entwicklung in erster Linie laufen.

b) Dann habe ich den kompletten Start. Hier wird dann aber in der Regel ein Deployen ausgeführt und am Ende läuft dann z.B. ein Tomcat mit einer vorgegebenen, lokalen Konfiguration auf einer Datenbank, die dann auch gewisse Daten enthält.
Für die Daten habe ich dann meist Scripts, so dass ich die Datenbank problemlos neu erstellen kann.

Aber das ganz wichtige sind die Unit Tests. Und diese haben dann auch - wo notwendig - Ressourcen, die geladen werden können. Und je nach Test gibt es dann halt gewisse Initialisierungsarbeiten und Aufräumarbeiten. Somit kann ein Unit Test z.B. sein, dass die Datenbank von Grund auf neu angelegt wird und dann alle Scripte laufen, um diese Datenbank von Schema Version zu Schema Version zu aktualisieren oder so ...

 

[White_Fox]

UnitTests hab ich auch, allerdings nicht für GUI-Elemente. Ich hab noch nicht gerafft, wie ich dafür Unittests schreiben kann, andererseits hab ich da leider noch recht große Abhängigkeiten zwischen den GUI-Klassen aufgrund diverser Probleme, die ich noch mit JavaFX habe. Irgendwann, vielleicht über Weihnachten, schmeiß ich es mal ins Internet und bitte hier um ein Review, und hätte euch dann mal gefragt wie ich das am Besten mache.

Also was startest Du denn genau? Ich fürchte, ich habe das noch nicht richtig verstanden.

Im Moment das Programm, wie es später ausgeführt werden soll.

Speichern und Laden von Daten ist im Moment noch nicht implementiert (und für die aktuelle Version auch noch nicht geplant), sonst würde ich einen "Testworkspace" einbauen der vom Build ausgeschlossen wird. Aber wie gesagt - aktuell ist das noch nicht.

 

[M.L.]

GUI-Elemente.(..) wie ich dafür Unittests schreiben kann,(..)

Muss man vielleicht nicht, ein Tool namens Ranorex kann man sich hierzu etwas genauer anschauen: https://www.ranorex.com/ (die Aktivierung via Firmen Emailadresse ist etwas umständlich, lässt sich über diese Downloadseite aber überwinden)

 

[mrBrown]

Du kannst auch einfach zusätzlich zu den Test-Klassen ganz normale "Main-Klassen" haben, die aber zu den Test-Source gehören. Die sollten sich genauso wie die normale Main ausführen lassen, und du kannst beliebige Daten drin vorbereiten, ohne aber das eigentliche Programm zu "zerstören".
Wenn ich deinen Ursprungspost richtig verstehe, hast du das auch versucht, es gab aber irgendwo Probleme?

Irgendwann, vielleicht über Weihnachten, schmeiß ich es mal ins Internet und bitte hier um ein Review, und hätte euch dann mal gefragt wie ich das am Besten mache.

Spricht was dagegen, das jetzt schon bei GitHub oä öffentlich zu stellen? Im Zweifel kann man dann direkt schon was zu einzelnen Punkten sagen

 

[White_Fox]

@M.L.
Ist das kostenlos nutzbar oder unterliegt es sonst einer Beschränkung? Das Programm (also daß, das ich schreibe) ist ein reines Freizeitprojekt (obgleich durchaus auch für die ein oder andere Firma nützlich ist), da kann und will ich keine großen Scheine einwerfen.

Spricht was dagegen, das jetzt schon bei GitHub oä öffentlich zu stellen?

Naja, im Moment ist da noch nichts außer daß man über ein Kontextmenü eine Tabelle füllen kann. Zumindest ist daß das, was man von außen sieht, hintenrum ist da schon eingiges mehr. Ich persönlich hätte das Programm schon gerne vor zwei Jahren fertig gehabt (ich habe aber erst vor anderthalb Jahren angefangen es zu schreiben) und einerseits treibt mich der Drang es endlich soweit fertig zu haben wie ich es mir vorstelle. Und andererseits muß ich daß erst in Gradle umfummeln,
So wie es jetzt aussieht kann man das ja niemandem zeigen, das ist ja nix Ganzes und nix Halbes...

 

[M.L.]

Ist das kostenlos nutzbar

die 30 Tage Trial Version ist kostenlos nutzbar, die Vollversion liegt im vierstelligen Bereich. Aber irgendwie erkennt das Setup frühere Ranorex Installationen, womit das jeweilige Windowssystem für einen längeren Versuchszeitraum als 30 Tage verbrennt. Von daher könnte R.x unter einem virtualisiertem Windows i.V. mit VMWare probiert werden.

 

[thecain]

30 Tage sollte ja auch reichen zum probieren.

 

[White_Fox]

Ich will es aber nicht probieren, sondern wenn schon, dann auch benutzen. Und in 30 Tagen werd ich mein Programm wahrscheinlich nicht fertig haben. Schade...wenn auch verständlich.

 

[mihe7]

Ich würde das UI nicht automatisiert testen, da mir das zu fragil wäre und es auch kaum etwas zu testen gibt. Solltest Du UI-Logik haben, die Du wirklich testen willst, dann kannst Du diese in eine separate Klasse ausgliedern. Dieses Vorgehen hat eine Bezeichnung, die mir aber gerade nicht einfällt...

EDIT: Humble Object Pattern... http://xunitpatterns.com/Humble Object.html

 

[White_Fox]

Nee, Logik ist da nicht drin. (Außer solcher Kram wie "Graue dies aus wenn ...".

 

[kneitzel]

Also Coded UI Tests kann man durchaus erstellen und da gibt es dann auch Open Source Tools für.

Bei Web Anwendungen wird Selenium (https://www.seleniumhq.org/) wohl recht stark genutzt. Wenn es aber nicht um Web Applikationen sondern um Desktop Apps geht, dann wird es etwas komplizierter. Ich habe da in der Vergangenheit mit SikuliX (http://sikulix.com/) gearbeitet.

Es gibt bestimmt auch noch deutlich mehr, aber das sind die (Open Source) Tools für UI Tests, mit denen ich in Berührung gekommen bin.

 

[mihe7]

Also Coded UI Tests kann man durchaus erstellen

Ja, ich habe mich oben sicher weit aus dem Fenster gelehnt. Das Hauptproblem, das ich mit diesen Tests habe, ist, dass sie vergleichsweise aufwändig umzusetzen sind und teilweise schon bei kleinsten Änderungen am UI fehlschlagen.

Hinzu kommt die Überlegung, was wird beim UI-Test getestet wird. Man sucht sich die betreffenden Elemente, führt "Operationen" (Klicks, Eingaben) auf ihnen aus und sieht sich an, ob die erwartete Veränderung am UI eingetreten ist. Das Gros ist dabei längst getestet: die Komponenten des UI-Frameworks und die Logik der Anwendung. Es geht letztlich nur noch um die konkrete Interaktion zwischen UI-Komponenten und der UI-Logik, sowie zwischen UI-Logik und Anwendungslogik. Letzteres lässt sich problemlos testen, so dass nur noch die Verbindung zwischen Komponenten und Logik übrig bleibt. Dafür ist mir der Aufwand für ein automatisiertes Testen auf GUI-Ebene zu hoch, insbesondere weil Fehler an dieser Stelle i. d. R. sofort auffallen.

 

[kneitzel]

Ja, das deckt sich mit meinen Erfahrungen.

Gerade bei SikuliX ist es sehr extrem, da hier ja alles rein graphisch erkannt wird. Selenium und so geht da schon relativ gut... (wobei wir in der Praxis die Coded UI Tests von Visual Studio hatten, aber das ist am ehesten mit Selenium vergleichbar (so man da überhaupt was vergleichen kann)....

SikuliX habe ich bisher nur einmal eingesetzt und da ging es nicht um Softwareentwicklung sondern um die Automatisierung eines idiotischen Spiels ...

 

[mihe7]

sondern um die Automatisierung eines idiotischen Spiels ...

lol, wer macht denn sowas?

 

[kneitzel]

lol, wer macht denn sowas?

Och, so Spiel Automatisierungen sind oft lustig, wenn der Spaß nachlässt oder es oft nur noch auf immer gleiche Dinge hinaus läuft ...

Am krassesten war es damals bei EverQuest. Da waren Bots inoffiziell geduldet, und da liefen dann Leute teilweise mit voller Gruppe rum. Ich war ‚nur‘ mit 3 Figuren unterwegs, aber war schon eine Herausforderung, dass man da mit beliebiger Kombination spielen konnte um dann zu testen, was wie effektiv war. (Und da musste viel entwickelt werden, um die Stärken der Klassen und das Zusammenspiel zu optimieren....)

Aber was erwartet man auch? Da gab es dann Quest Reihen für die epic Waffe der Klasse, da musste man an einem Punkt einen speziellen Mob killen .... Spawn Zeit waren dann so ich mich recht entsinne um die 1-2 Stunden, die Chance auf den Mob war aber schon relativ klein. Und dann die Dropchance ebenso... als Spieler ohne mob hat Ma sich da dann an der Stelle ausgeloggt um sich dann regelmäßig einzuloggen, Mob umhauen und wieder schlafen legen .... und das über teilweise 1 - 2 Wochen .... krank ... dann lieber bot laufen lassen, da hat man dann die 1-2 Wochen auch warten müssen, aber in der Zeit hat die kleine Gruppe in der Gegend um den Spawnpunkt alle Mobs platt gemacht für Erfahrung und Weitere Drops ....

 

[mihe7]

Oje, ich versteh nur Bahnhof - von derlei Spielen weiß ich absolut null. Ich kenne noch nicht mal die Titel. World of Warcraft ist mir vom Namen her noch bekannt, das wars aber auch schon

Mit Commander Keen kann ich dienen

 

[kneitzel]

Oje, ich versteh nur Bahnhof - von derlei Spielen weiß ich absolut null. Ich kenne noch nicht mal die Titel. World of Warcraft ist mir vom Namen her noch bekannt, das wars aber auch schon

Mit Commander Keen kann ich dienen

Hast auch nicht wirklich was verpasst. EverQuest war sozusagen ein Vorläufer von World of Warcraft.

 

[White_Fox]

Ok, wenn ich mir eure Argumente so anschaue, werde ich auf UI-Tests verzichten. Das UI wird sich nämlich tatsächlich noch erheblich verändern, hintenrum ist bereits eine Menge entwickelt was ich lediglich nur noch nicht darstelle.

Außerdem sehe ich noch ein paar andere Vorteile, das UI händisch zu testen:

• Es steigert Vorfreude und Motivation gleichermaßen, wenn man sein Werk auch öfter mal betrachten kann.
• Während der bisherigen UI-Entwicklung sind mir noch die ein oder anderen Fehler aufgefallen, die durch meine Unittests durchgerutscht sind.

Beide Punkte finde ich eher vorteilhaft und will ich ohne Not auch nicht aufgeben.

@kneitzel
Interessant was du sonst so alles machst...

 

[mrBrown]

Wobei es trotzdem Sinn haben kann, Testfälle für die UI zu schrieben (zB in Gherkin) die man dann nicht automatisiert testet, sondern nur per Hand durchgeht. Hat mir schon ein paar mal den Arsch gerettet...

Und falls man doch irgendwann mal automatisiert testen will, hat man die Testfälle schon ausformuliert.