Hallo,
mich würde mal interessieren wie eure Unit tests aussehen. Was genau versteht ihr darunter? Habt ihr für jede Methode mindestens einen Test? Habt ihr nur für öffentliche Methoden einen test? Testet ihr wenn ihr eine Methode testet auch die von ihr aufgerufenen Methoden oder erstellt ihr für diese Methode wieder einen extra test? Oder erstellt ihr ein paar Unit tests mit der ihr eine komplette assembly testet?
Viele Grüße,
Zottell
Hallo Zottell,
mit einem _Unit _Test wird eine (!) _Unit _getestet, s. Single Responsibility Principle. Du sollst also ++nicht ++einen 500-zeiligen Unit Test schreiben, der eine gesamte Assembly testet. Stattdessen sollst du einzelne Unit Tests schreiben, die eine jeweils spezifische Funktionalität testen.
Wenn man testgetrieben entwickelt, hat jede öffentliche Methode einen oder mehrere zugehörige Tests. Auch dann, wenn man nicht TDD praktiziert, ist eine möglichst hohe Testabdeckung anzustreben.
Die Frage, ob private Methoden direkt getestet werden sollten, beantwortet herbivore sehr gut in Tatsächlicher Nutzen von Unit-Tests [und TDD]:
gerade mit Blick auf den Nutzen von Unit-Tests beim Refactoring ist es kontraproduktiv, private Methoden direkt zu testen, statt nur indirekt über öffentliche Methoden, weil du dann nach einer Änderung der Implementierung die Tests nicht einfach unverändert laufen lassen kannst, um eine verlässliche Aussage über die Korrektheit der Änderungen zu bekommen, sondern die Tests erst anpassen musst.
m0rius
Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg
Hallo mOrius,
danke für deine Antwort, aber vielleicht war meine Frage nicht klar. Ich möchte nicht wissen was ein Unit test ist, sondern was einzelne Entwickler darunter verstehen und wie sie es praktizieren. Ich habe mittlerweile zwei Extreme kennengelernt. Das eine Extrem testet alles, und verwendet nur öffentliche Methoden wegen der besseren Testbarkeit, wärend das andere extrem einen Test für einen Controller schreibt und damit auch das Model testet. Bitte keine Vor und Nachteile nenne und nicht, das ist aber kein Unit test mehr, sondern lediglich wie es von euch praktiziert wird.
Hallo Zottell,
ich schreibe die Test so, wie ich sie oben beschrieben habe. Ein Test pro Controller, der gleichzeitig das Model mittestet, ist demnach großer Blödsinn.
m0rius
Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg
Hallo Zottell,
Ich möchte nicht wissen was ein Unit test ist, sondern was einzelne Entwickler darunter verstehen und wie sie es praktizieren.
diesen Wunsch sollte dir der von m0rius verlinkte Thread sehr ausführlich erfüllen. Es macht keinen Sinn, das hier nochmals aufzurollen.
Bitte keine Vor und Nachteile nenne und nicht, das ist aber kein Unit test mehr, sondern lediglich wie es von euch praktiziert wird.
Das kann man nicht trennen bzw. wenn man es trennt wird es witzlos. Und in dem verlinkten Thread wurde es auch nicht getrennt.
herbivore
Manch ein Entwickler glaubt mit seinen Unittests, die des öfteren automatisiert durch Continous Integration Tools wie Hudson ausgeführt werden ein richtiger Crack in der Qualitätssicherung zu sein.
Für mich aber definiert sich Qualitätssicherung so -> ISO 9126
Unittests zu schreiben ist manchmal auch gar nicht so richtig möglich, in verteilten Anwendungen müsste man dan plötzlich Verbindungspartner simulieren usw.
Ich bin ein Entwickler der davon überzeugt ist das Unittests die durch CI regelmäßig ausgeführt werden viel zu QS beitragen. Allerdings müssen die tests sinnvoll sein und auch das testen was gewollt ist und nichts anderes 😃
Aber wie MrFluffy, schon gesagt hat ist es manchmal nicht möglich, da hilft nur Hand anlegen (lassen) 😉
Gruß
private int Main()
{
string programmingSkills = getMySkills("programming")
return = 1;
}
Ich entwickel nicht TDD und teste die fehleranfälligen Bereiche.
Eine GUI teste ich nicht, wenn da was falsch gezeichnet wird, sehe ich es...
Bei großen Algorithmen teste ich auch schon mal private Methoden. Ein Unit Test soll mir helfen, den Fehler möglichst früh zu finden. Wenn nun ein Algorithmus intern als 15 Methode a 20 Zeilen besteht, die ich aber einzeln testen kann, hilft mir das bei der Fehlersuche eher, als wenn der Gesamttest fehl schlägt.
Vorgehensweise (auch wenn nicht nach Lehrbuch...): Ich implementiere erst, schaue ob das rauskommt, was ich erwarte, und debugge dann mit Unit Tests. Nehme mir also so lange Blöcke vor und Teste diese, bis das Programm läuft, wie erwartet.
@Uwe81:
Da hast du aber ( wie so viele ) den Sinn und Zweck von Unittests nicht so wirklich durchdrungen.
Unittests sind nicht nur dazu da, zu testen ob du aktuell die Funktion richtig implementiert hast, sondern dieser Test soll in der Zukunft zeigen das du die Funktion nicht "kaputt" machst durch andere Aktionen.
Es soll beim ständig nötigen Refaktoring helfen, nicht irgendwas einzureissen was mal funktionierte.
Und wenn du nach einer Änderung im Validationframework dann z.b. 500 Eingabemasken durchgehen musst um zu überprüfen das es sich noch so verhält wie vorher, verbrennst du unnötig viel Zeit.
Ganz abgesehen davon das du nach ein paar stunden auch Fehler nicht mehr siehst.
@MrFluffy:
Unittests zu schreiben ist manchmal auch gar nicht so richtig möglich, in verteilten Anwendungen müsste man dan plötzlich Verbindungspartner simulieren usw.
Gerade in diesem Fall zeigt sich dann auch, ob richtig Architektur betrieben wurde.
Nur weil etwas aufwendiger zu testen ist soll man das also sein lassen?
Schonmal was von Interfaces und/oder Mocking gehört?
Essentiell sind vor allem Integration- und Regressionstests, es hilft z. B. nichts eine Komponente zu bauen die zwar funktioniert aber nicht im System selbst richtig läuft
Aber über Software Qualitätssicherung kann man sich stundenlang unterhalten bzw. Bücher schreiben.
Eines z. B. wäre
Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard
Was ich vorhin mit Hudson gemeint ist folgendes, man entwickelt in einem Versionsverwaltungssystem zusammen mit anderen Entwicklern eine Software und fügt dort u. A. auch die Unittests hinzu.
Hudson oder ein Vertreter dieser Gattung "Contiunous Integration", holen sich dann z. B. eine aktuelle Version der Software, deployen diese und führen die Unitstest vollautomatisiert aus. Läuft dann etwas schief gibt es gleich eine Nachricht.
Ich kenne Hudson und auch andere CI, ich setze z.b. TeamCity ein.
Essentiell sind vor allem Integration- und Regressionstests, es hilft z. B. nichts eine Komponente zu bauen die zwar funktioniert aber nicht im System selbst richtig läuft
Dann hat derjenige der die Unittest der Komponente betreibt nicht verstanden das die öffentliche Schnittstelle einer Komponente das wichtigste ist was getestet werden muss.
Und wenn Du manuelle Integration- und Regressionstests als für das wichtigste ansiehst, kannt du nur in einem Amt sitzen, wo die Zeit "nicht bezahlt" werden muss.
Alles was automatisch getestet werden kann, sollte auch so gemacht werden.
Natürlich muss man diese Tests von zeit zu Zeit überprüfen, aber das weis ein Testmanager ja.
Aber über Software Qualitätssicherung kann man sich stundenlang unterhalten bzw. Bücher schreiben.
Nicht unterhalten oder Bücher schreiben, sondern praktizieren.
Eines z. B. wäre
Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard
Richtig, und genau da wird auch gelehrt das man eben nicht mit Regressions und Integrationstests alleine auskommt.
Soltest du tatsächlich so einen Lehrgang schon mal gemacht haben und nichts zu Unittests gehört haben, dann solltest Du das Geld zurückverlangen.
Aber du hast sicher auch recht das es Leute gibt die Unittests schreiben um Testabdeckung zu haben, ohne das wirklich etwas vernünftiges bei rauskommt.
Nur Du darfst nicht die Stümper hernehmen um das System zu verteufeln.
Nicht jeder Arzt ist ein Schlächter, nur weil einige zu dumm sind das vernünftig anzuwenden was stand der aktuellen Erkenntnisse ist.
Wir müssen uns glaube ich nicht darüber unterhalten wie man mit Unittests zu gange ist.
Ich wollte lediglich zum Ausdruck bringen das Regressions- als auch Integrationstests für mich persönlich sehr wichtig sind. Unittests sollten/werden durch CI oder welche Mechanik auch immer kontinuierlich durchgeführt.
Das Buch habe ich nur verlinkt da ich es als gut empfinde und hier auch klar wird was gute Tests ausmachen. Insbesondere sollte das die Fragen des Threaderstellers beantworten.
Man darf heutzutage ja schon froh sein wenn Unitstests nicht wegrationalisiert wurden. Hatte in meinem damaligen Praktikum miterleben dürfen, was so alles unter der Ausrede "keine Zeit -> Release" alles vernachlässigt wurde 😉