Hallo!
Ich beschäftige mich jetzt seit einiger Zeit mit dem Testen von Software. Welche Arten von Tests gibt es? Welche Test können automatisch laufen? usw. Beginnen möchte ich mit den Unit Tests. Nur ich habe da noch etwas Verständnisschwierigkeiten, was man mit Unit Tests abdecken kann und was nicht. Und wie muss ein Projekt/Programm aufgebaut sein, wenn man Unit Tests verwenden möchte? Kann man Unit Test in vorhandene Projekte einbauen?
In der Qt-Doku kann man im Beispiel sehen, dass dort die toUpper()-Funktion von QString getestet wird, was auch einleuchtend ist. Nur kann ich eine Methode testen, die zB. per SQL Datensätze auf einer DB holt und diese dann in Form eines Lieferscheins in ein PDF schreibt? Jeder kann sich vorstellen, dass dort mehr passiert. Muss man solche Methoden noch weiter verkleinern, damit Unit Tests funktionieren oder ist das Testen so einer Art von Methode unmöglich (außer manueller Test vom Benutzer)?
Viele Fragen, aber ich hoffe auf ein paar informative Hinweise.
Markus
Unit Test / Modultest
Re: Unit Test / Modultest
generell, Sinn eines UnitTests ist es, Basis-Funktionen einer Unit (meist klasse) zu testen.
Schreibst Du tests, wo zigtausend Units dran beteiligt sind, iss das kaum noch nen Unittest
sondern nen funktionaler Test / Integrationstest ....
Die Uebergaenge sind fliessend.
nen merkmal der "eigentlichen" UnitTests ist aber, das der unittest durchs framework beim kompilieren immer ausgefuehrt wird, also da alle Bedingungen gegeben sein muessen, um den test erfolgreich zu absolvieren (ist doof wenn man dann noch 100 andere kompnenenten oder plugins / module oder gar ne tcp/ip verbindung braucht, das schränkt die möglichkeiten des kompilierens dann ein).
Und wenn man oefters kompiliert, sollten die Tests dann auch fix gehen ^^ es macht kein sinn, 2 min zu kompilieren, und dann 2h auf den Unittest zu warten
Das schoene an Unittests ist, schreiben, ins Project einklinken, vergessen. wenn die mal fehlschlagen, dann iss wirklich was faul
grössere Projecte haben deshalb meist mehrere Arten von "Entwicklertests" (tests die die Entwickler machen, bevor es in die QA geht).
Unittests, Integrationstests, eigene Testprogramme ....
Ciao ...
Schreibst Du tests, wo zigtausend Units dran beteiligt sind, iss das kaum noch nen Unittest
![Smile :-)](./images/smilies/icon_e_smile.gif)
Die Uebergaenge sind fliessend.
nen merkmal der "eigentlichen" UnitTests ist aber, das der unittest durchs framework beim kompilieren immer ausgefuehrt wird, also da alle Bedingungen gegeben sein muessen, um den test erfolgreich zu absolvieren (ist doof wenn man dann noch 100 andere kompnenenten oder plugins / module oder gar ne tcp/ip verbindung braucht, das schränkt die möglichkeiten des kompilierens dann ein).
Und wenn man oefters kompiliert, sollten die Tests dann auch fix gehen ^^ es macht kein sinn, 2 min zu kompilieren, und dann 2h auf den Unittest zu warten
Das schoene an Unittests ist, schreiben, ins Project einklinken, vergessen. wenn die mal fehlschlagen, dann iss wirklich was faul
![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
grössere Projecte haben deshalb meist mehrere Arten von "Entwicklertests" (tests die die Entwickler machen, bevor es in die QA geht).
Unittests, Integrationstests, eigene Testprogramme ....
Ciao ...