Laden...

Wie kann ich beim Testen _alle_ Fälle abdecken?

Erstellt von Unfug vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.744 Views
U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 4 Jahren
Wie kann ich beim Testen _alle_ Fälle abdecken?

Hallo zusammen,

wir stellen uns die einfachste Variante vor:

Chef zu Neuling: Mach ein Registerformular, 2 Felder. Email und Passwort.

Neuling programmiert:

Register(string email, string passwort)

Tester:

Register("haha", " ")

Neuling: Ok...jetzt mit Prüfung

Register(string email, string passwort)
{
email muss @ und . haben
passwort darf nicht leer sein
}

Tester:

Register(" M ail+@harhar.de"," lere bi ich nicht°1")
...
...

Never Ending Story.

Meine Frage: Unittests wären hier nicht zielführend für den Neuling gewesen, denn der Code und die Tests würden irgendetwas übersehen. Bei 100 Abdeckung wären die Tests nur für die Email kilometerlang.
Alles mit Regex prüfen ? Was ist bei komplexen Datenobjekten?

Wie kann man derartige "Einschränkungen" direkt mitgeben und vor allendingen testen?
Im Web kennen wir Validierungen, wo die Regeln teilweise auch kilometerlang sind. Gibt es hier nicht elegantere Lösungen?
Gerade, wenn man mit Endanwendern arbeitet, die finden immer etwas - aber immer dann wenn etwas produktiv geht.

Danke

16.807 Beiträge seit 2008
vor 4 Jahren

Es gibt einfach nicht das pauschal beste Testen. Davon muss man sich leider verabschieden.

AutoFixture ist im .NET Umfeld sehr weit verbreitet, was das Generieren von Test-Daten betrifft.
Validierungen sind kein Web-unique Feature. Das kann man überall verwenden.

Testen ist genauso Programmieren wie produktiver Code.
Und dazu gehört genauso Erfahrung wie zu allen anderen Bereichen.

3.003 Beiträge seit 2006
vor 4 Jahren

Ich finde auch die Aussage irritierend, Unit Tests würden hier nichts nutzen, weil man ja etwas übersehen würde.

"Wir können Methode xy nicht benutzen, weil wir sie falsch/unvollständig nutzen würden."

Äh, was?

Inputvalidierungen lassen sich sehr gut per Komponententest prüfen. Voraussetzung wäre natürlich, dass man weiss, was ein valider Input ist. Andererseits macht die Angabe "validiere xyz", ohne festzulegen, was ein valider Wert ist, noch weniger Sinn als die Aussage oben.

LaTino
(Disclaimer: Wenn die Teststrategie NUR aus Komponententests besteht, ist selbstredend auch was verkehrt. Mich hatte nur die Aussage irritiert.)

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Unfug
Was Unit Tests betrifft, kann ich mich nur LaTino und Abt anschließen.
Gerade bei Unit Tests muss man die max. Abdeckung auch selbst erreichen.
Genau dies ist aber auch ein Nutzen von Unit Tests.
Man will eben zum einem sicherstellen, dass der eigene Code bei Änderungen noch funktioniert und das richtige Ergebnis liefert aber auch mögliche Fehlerfälle abdecken.

Dazu gehört dann eben auch durch falsche/fehlende Eingaben bei den jeweiligen Methoden/Klassen sicherzustellen, dass diese den Fehlerfall erkennen und verarbeiten können.
Bei Email Validierungen, gibt es im Netz z.B. unmengen an Beispielen für RegEx Lösungen.
Ich hatte hier auch mal den Ansatz gewählt über die MailAddress Klasse von .NET einfach prüfen zu lassen ob die Email gültig ist.
Dort kümmert man sich bereits um alle möglichen Probleme mit fehlerhaften Eingaben, man muss halt nur beachten, dass auch lokale Domain Adresen wie "Benutzer@Home" gültig sind.

Ansonsten ist die Empfehlung immer Unit Tests schreiben.
Wir haben dies Jahre lang bei uns vernachlässigt, was nun viel Nacharbeit erfordert, wenn kritische Komponenten angefasst werden müssen.
Entsprechend ist es weniger Arbeit, die Tests direkt umzusetzen als diese erst viel später ins Projekt einzubinden.
Diese komplett auszuklammern, weil man mehr Code schreiben muss, ist eine sehr dumme Entscheidung die bei großen Projekten auf lange Sicht zu mehr Problemen führen als mit Unit Tests!
Und eine spätere Einführung scheitert in den meisten Projekten, wenn diese einfach einen gewissen Zeitpunkt überschritten haben.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 4 Jahren

Hallo zusammen,

Danke für die Antworten. Ich bin absolut nicht gegen UnitTests. Im Gegenteil.
Hätte nur gedacht hier gibt es Best Practice Erfahrungen, die einen noch besser helfen.

Oft sind die UnitTests ja sehr klein und granular gehalten, aber dann wiederum nicht immer ausreichend. Gerade wenn ich komplexe Objekte in komplexen Methoden teste...eieiei.

Ich finde die Aussage von ABT:

Testen ist genauso Programmieren wie produktiver Code.
Und dazu gehört genauso Erfahrung wie zu allen anderen Bereichen.

eigentlich perfekt. Es würde aber auch bedeuten, dass man dem Neuling nichts an die Hand geben kann außer: Lerne aus Erfahrungen.
Dachte hier gibt es ggfs. mehr Ansätze.

16.807 Beiträge seit 2008
vor 4 Jahren

Es würde aber auch bedeuten, dass man dem Neuling nichts an die Hand geben kann außer: Lerne aus Erfahrungen.

Nein, tut es nicht!
Das habe ich weder in der Art noch Inhaltlich gesagt.
Und ich empfinde es als sehr fragwürdig, wenn das Dein Fazit ist.

Egal welche Stufe man selbst ist: man lernt immer dazu.
Und lernen tut man von anderen, durch Eigeninitative oder von Fehlern.

Man kann von niemanden erwarten, dass am Ende perfekter Code raus kommt.
Ein Anfänger hat genauso das Vertrauen in seine Fähigkeiten verdient wie ein 10x Profi.

Ich hoffe wirklich, dass Du in dieser Ausdruckweise Anfänger nicht behandelst.

49.485 Beiträge seit 2005
vor 4 Jahren

Hallo zusammen, hallo Unfug,

ich lese aus dem resignierten Unterton in "dass man dem Neuling nichts an die Hand geben kann außer: Lerne aus Erfahrungen", dass du Neulinge gerade nicht damit abspeisen willst, sondern nach einer echten Hilfe suchst, die du ihnen an die Hand geben kannst.

Ich bedauere ehrlich gesagt auch als Erfahrener immer wieder, wie viele Fälle man bei Unit-Tests berücksichtigten muss ... und dann immer noch nicht die volle Komplexität abgedeckt hat. Selbst bei einfachen Methoden übersteigt die Codelänge der Unit-Tests die der zu testenden Methode oft um ein Vielfaches.

Und dass wäre schon mal ein erster Rat, den man Anfängern auf den Weg geben kann: Wenn deine Unit-Tests kürzer sind, als der Code der Methode, dann fehlen vermutlich noch viele wichtige Fälle.

Außerdem muss man nachdrücklich klar machen, dass Unit-Tests nicht nur die Gutfälle berücksichtigen sollen, sondern besonders (fast schon vorrangig) auch die Schlecht- und Fehlerfälle.

Und dann finde ich es wichtig, die Haltung zu vermitteln, dass es bei Unit-Tests nicht darum geht, sich in dem Glauben zu bestätigen, dass man die Methode richtig programmiert hat. Sondern dass man ganz im Gegenteil alles daran setzen sollte, zu beweisen, dass in der Methode noch Fehler sind. Es ist ein bisschen so, wie wenn man gegen sich selber Schach spielt. Da geht man als Schwarz auch nicht davon aus, dass man als Weiß alles richtig gemacht hat und dagegen sowieso nicht anzukommen ist, sondern man setzt alles daran, die Lücken zu finden, die Weiß gelassen hat.

So sind auch Unit-Tests ein (ernsthaftes) Spiel gegen sich selber. Als Weiß versucht man die perfekte, fehlerfreie Methode zu schreiben und als Schwarz setzt man alles daran, die Schnitzer und Lücken zu finden, die Weiß doch übersehen oder gelassen hat. Und je mehr man davon findet, desto besser ist man. Nicht nur ein desto besserer Unit-Tester ist man, sondern ein desto besserer Programmierer ist man. Denn am Ende wird man danach gemessen, wie fehlerfrei der produktive Code ist, nicht danach, wie fehlerfrei eine Methode im ersten Anlauf (also vor den Unit-Tests) war.

Und man wird durch diese zwei Perspektiven sogar noch ein besserer Programmierer. Denn wenn man sich beim Programmieren bewusst ist, dass man sich selbst während der Unit-Tests auf eine wirklich harte Probe stellen wird, wird man schon beim Programmieren immer besser wissen, was man alles gleich berücksichtigen, einbauen und unterlassen muss, um in ersten Anlauf möglichst wenig Fehler zu machen.

herbivore

U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 4 Jahren

@Abt: Um Gotteswillen! Ich würde hier ja nicht nachfragen, wenn ich so ein Verhalten an den Tag legen würde. Es geht mir ja darum, Neulinge noch besser an die Hand zu nehmen und nicht nur durch Erfahrungen zu profitieren - daher ja die Nachfrage nach Best Practice.

@herbivore:

Sondern dass man ganz im Gegenteil alles daran setzen sollte, zu beweisen, dass in der Methode noch Fehler sind.

Schöner Gedanke. So habe ich es ehrlich gesagt noch nie gesehen. Die Tatsache, dass man den Blickwinkel auf einen UnitTests ändert, eröffnet durchaus neue Ideen.

3.003 Beiträge seit 2006
vor 4 Jahren

https://twitter.com/brenankeller/status/1068615953989087232

Wäre das Testen von Code ein gelöstes Problem, gäbe es weder Witze darüber, noch fehlerhafte Software.

Ein Testcoverage-Tool, das dir anzeigt, welche Zeilen bereits im Rahmen eines Tests durchlaufen wurden, kann helfen, ungeprüfte Fälle zu finden. Ich benutze dafür dotcover (Resharper). So ein Tool prüft natürlich nicht, ob das Test selber die richtigen Überprüfungen macht. Ist aber dennoch ein sehr guter Helfer dabei, Testfälle zu entdecken, die man übersehen hatte.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)