myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Rund um die Programmierung » Wie kann ich beim Testen _alle_ Fälle abdecken?
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Wie kann ich beim Testen _alle_ Fälle abdecken?

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Unfug
myCSharp.de-Mitglied

Dabei seit: 25.07.2006
Beiträge: 117


Unfug ist offline

Wie kann ich beim Testen _alle_ Fälle abdecken?

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo zusammen,

wir stellen uns die einfachste Variante vor:

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

Neuling programmiert:

C#-Code:
Register(string email, string passwort)

Tester:

C#-Code:
Register("haha", " ")

Neuling: Ok...jetzt mit Prüfung

C#-Code:
Register(string email, string passwort)
{
email muss @ und . haben
passwort darf nicht leer sein
}

Tester:

C#-Code:
Register(" M [email protected]"," 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
Neuer Beitrag 15.03.2020 19:26 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.943
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
Neuer Beitrag 15.03.2020 20:20 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.998
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.)
Neuer Beitrag 15.03.2020 20:28 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.551
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@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 "[email protected]" 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
Neuer Beitrag 16.03.2020 08:14 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Unfug
myCSharp.de-Mitglied

Dabei seit: 25.07.2006
Beiträge: 117

Themenstarter Thema begonnen von Unfug

Unfug ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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:

Zitat:
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.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Unfug am 16.03.2020 16:01.

Neuer Beitrag 16.03.2020 16:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.943
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Unfug:
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.
Neuer Beitrag 16.03.2020 16:03 Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.475
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
Neuer Beitrag 17.03.2020 08:16 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Unfug
myCSharp.de-Mitglied

Dabei seit: 25.07.2006
Beiträge: 117

Themenstarter Thema begonnen von Unfug

Unfug ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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

Zitat:
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.
Neuer Beitrag 17.03.2020 10:44 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.998
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

 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
Neuer Beitrag 17.03.2020 12:09 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 3 Monate.
Der letzte Beitrag ist älter als 3 Monate.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 06.07.2020 19:55