Laden...

Was genau gehört in einen Unit test.

Erstellt von Zottell vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.134 Views
Z
Zottell Themenstarter:in
21 Beiträge seit 2007
vor 13 Jahren
Was genau gehört in einen Unit test.

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

1.002 Beiträge seit 2007
vor 13 Jahren

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

Z
Zottell Themenstarter:in
21 Beiträge seit 2007
vor 13 Jahren

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.

1.002 Beiträge seit 2007
vor 13 Jahren

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

49.485 Beiträge seit 2005
vor 13 Jahren

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

M
32 Beiträge seit 2011
vor 13 Jahren

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.

S
341 Beiträge seit 2008
vor 13 Jahren

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ß

**Nur die Kenner können mit 10 Fingern bis 1023 zählen !!**
private int Main()
{
   string programmingSkills = getMySkills("programming")
   return = 1;
}
U
282 Beiträge seit 2008
vor 13 Jahren

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.

F
10.010 Beiträge seit 2004
vor 13 Jahren

@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?

M
32 Beiträge seit 2011
vor 13 Jahren

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.

F
10.010 Beiträge seit 2004
vor 13 Jahren

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.

M
32 Beiträge seit 2011
vor 13 Jahren

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 😉