it-swarm.dev

Wann ist es angebracht, keinen Unit-Test durchzuführen?

Ich arbeite in einer kleinen Firma als Einzelentwickler. Tatsächlich bin ich der einzige Entwickler im Unternehmen. Ich habe mehrere (relativ) große Projekte, die ich regelmäßig geschrieben und gepflegt habe, und keines von ihnen hat Tests, um sie zu unterstützen. Wenn ich neue Projekte beginne, frage ich mich oft, ob ich einen TDD-Ansatz ausprobieren sollte. Es klingt nach einer guten Idee, aber ich kann die zusätzliche Arbeit ehrlich gesagt nie rechtfertigen.

Ich arbeite hart, um in meinem Design vorausschauend zu sein. Mir ist klar, dass sicherlich eines Tages ein anderer Entwickler meinen Code warten oder zumindest Fehler beheben muss. Ich halte die Dinge so einfach wie möglich und kommentiere und dokumentiere Dinge, die schwer zu verstehen wären. Tatsache ist, dass diese Projekte nicht so groß oder kompliziert sind, dass ein anständiger Entwickler Schwierigkeiten haben würde, sie zu verstehen.

Viele der Beispiele, die ich für Tests gesehen habe, gehen auf die Details zurück und decken alle Facetten des Codes ab. Da ich der einzige Entwickler bin und dem Code im gesamten Projekt sehr nahe bin, ist es viel effizienter, einem Muster zu folgen, bei dem geschrieben und dann manuell getestet wird. Ich finde auch, dass sich Anforderungen und Funktionen häufig genug ändern, so dass das Aufrechterhalten von Tests ein Projekt erheblich belasten würde. Zeit, die sonst für die Lösung der Geschäftsanforderungen aufgewendet werden könnte.

So komme ich jedes Mal zu dem gleichen Schluss. Die Kapitalrendite ist zu niedrig.

Ich habe gelegentlich einige Tests eingerichtet, um sicherzustellen, dass ich einen Algorithmus korrekt geschrieben habe, z. B. die Berechnung der Anzahl der Jahre, die jemand im Unternehmen war, basierend auf dem Einstellungsdatum. Aber vom Standpunkt der Codeabdeckung aus habe ich ungefähr 1% meines Codes abgedeckt.

Würden Sie in meiner Situation immer noch einen Weg finden, Unit-Tests zu einer regelmäßigen Praxis zu machen, oder bin ich berechtigt, diesen Aufwand zu vermeiden?

PDATE : Ein paar Dinge über meine Situation, die ich ausgelassen habe: Meine Projekte sind alle Webanwendungen. Um meinen gesamten Code abzudecken, müsste ich automatisierte UI-Tests verwenden, und in diesem Bereich sehe ich immer noch keinen großen Vorteil gegenüber manuellen Tests.

143
Ken Pespisa

Viele der Beispiele, die ich für Tests gesehen habe, gehen auf die Details zurück und decken alle Facetten des Codes ab.

Damit? Sie müssen nicht testen alles. Nur die relevanten Dinge.

Da ich der einzige Entwickler bin und dem Code im gesamten Projekt sehr nahe bin, ist es viel effizienter, einem Muster zu folgen, bei dem geschrieben und dann manuell getestet wird.

Das ist eigentlich falsch. Es ist nicht effizienter. Es ist wirklich nur eine Gewohnheit.

Andere Solo-Entwickler schreiben eine Skizze oder einen Umriss, schreiben die Testfälle und füllen den Umriss mit dem endgültigen Code aus.

Das ist sehr, sehr effizient.

Ich finde auch, dass sich Anforderungen und Funktionen häufig genug ändern, so dass das Aufrechterhalten von Tests ein Projekt erheblich belasten würde.

Das ist auch falsch. Die Tests sind nicht der Widerstand. Die Anforderungsänderungen sind der Widerstand.

Sie müssen die Tests korrigieren, um die Anforderungen widerzuspiegeln. Ob ihre Minutien oder auf hohem Niveau; zuerst geschrieben oder zuletzt geschrieben.

Der Code wird erst ausgeführt, wenn die Tests bestanden wurden. Das ist die einzige universelle Wahrheit von Software.

Sie können einen eingeschränkten Abnahmetest "hier ist es" durchführen.

Oder Sie können einige Unit-Tests haben.

Oder Sie können beides haben.

Aber egal was Sie tun, es gibt immer einen Test, um zu demonstrieren, dass die Software funktioniert.

Ich würde vorschlagen, dass ein bisschen Formalität und eine nette Unit-Test-Tool-Suite diesen Test viel nützlicher machen.

85
S.Lott

Stellen Sie sich vor, Sie hätten eine Reihe von Tests, die in einem Augenzwinkern ausgeführt werden könnten und ein grünes oder rotes Licht aufleuchten lassen würden. Stellen Sie sich vor, dass diese Testsuite getestet wurde alles! Stellen Sie sich vor, Sie müssten nur ^ T eingeben, um die Testsuite auszuführen. Welche Kraft würde dir das geben?

Könnten Sie den Code ändern, ohne befürchten zu müssen, etwas zu beschädigen? Könnten Sie eine neue Funktion hinzufügen, ohne befürchten zu müssen, eine alte Funktion zu beschädigen? Könnten Sie unordentlichen Code schnell bereinigen, ohne Angst zu haben, Schaden zu verursachen?

Ja, du könntest all diese Dinge tun! Und was würde mit Ihrem Code im Laufe der Zeit passieren? Es würde immer sauberer werden, da kein Risiko für die Reinigung besteht.

Stellen wir uns vor, Sie hätten eine kleine Fee auf der Schulter. Jedes Mal, wenn Sie eine Codezeile geschrieben haben, hat die Fee der Testsuite etwas hinzugefügt, das getestet hat, dass diese Codezeile das getan hat, was sie beabsichtigt hatte. Sie konnten also alle paar Sekunden ^ T drücken und sehen, dass die letzte Codezeile, die Sie geschrieben haben, funktioniert hat.

Wie viel Debugging würden Sie Ihrer Meinung nach tun?

Wenn das nach Fantasie klingt, haben Sie Recht. Aber die Realität sieht nicht viel anders aus. Ersetzen Sie den Eyeblink durch ein paar Sekunden und die Fee durch die TDD-Disziplin, und Sie haben es so ziemlich verstanden.

Angenommen, Sie kehren zu einem System zurück, das Sie vor einem Jahr erstellt haben, und Sie haben vergessen, wie Sie eines der zentralen Objekte erstellen. Es gibt Tests, die dieses Objekt auf jede erdenkliche Weise erstellen. Sie können diese Tests lesen und Ihr Gedächtnis auffrischen. Müssen Sie eine API aufrufen? Es gibt Tests, die diese API auf jede erdenkliche Weise aufrufen. Diese Tests sind wenig Dokumente, geschrieben in einer Sprache, die Sie verstehen. Sie sind völlig eindeutig. Sie sind so formal, dass sie ausgeführt werden. Und sie können nicht nicht mehr mit der Anwendung synchronisiert werden!

Die Investition nicht wert? Du willst mich wohl veralbern! Wie könnte jemand diese Reihe von Tests NICHT wollen? Tun Sie sich selbst einen Gefallen und hören Sie auf, über Albernheit zu streiten. Lernen Sie, wie man TDD gut macht, und beobachten Sie, wie viel schneller Sie fahren und wie viel sauberer Ihr Code ist.

113
Uncle Bob.

Der Fehler, den Sie machen, ist, dass Sie das Testen als Zeitinvestition ohne sofortige Rendite betrachten. Das muss nicht unbedingt so sein.

Das Schreiben von Tests wirklich konzentriert Sie darauf, was dieser Teil Ihres Codes tun muss.

Wenn Sie sie zweitens ausführen, werden Fehler angezeigt, die sonst beim Testen auftreten würden.

Drittens zeigt das Ausführen manchmal Fehler, die sonst beim Testen nicht auftauchen würden und Sie dann in der Produktion wirklich in den Arsch beißen würden.

Viertens: Wenn Sie einen Fehler mit einem laufenden System feststellen und einen Komponententest dafür erstellen, können Sie diesen Fehler später nicht erneut einführen. Das kann eine große Hilfe sein. Wieder eingeführte Fehler sind häufig und sehr ärgerlich.

Fünftens: Wenn Sie jemals Code an eine andere Person weitergeben müssen, erleichtert eine Testsuite deren Leben erheblich. Auch wenn Sie ein Projekt ignoriert haben und nach einigen Jahren wieder darauf zurückkommen, werden Sie nicht mehr so ​​nah dran sein und es wird auch für Sie hilfreich sein.

Ich habe durchweg die Erfahrung gemacht, dass während der Entwicklung eines Projekts anständige Unit-Tests den Prozess immer schneller und zuverlässiger gemacht haben.

34
glenatron

Die Jungs von JUnit (Java Unit Test Framework) haben die Philosophie, dass wenn es zu einfach zu testen ist, es nicht testen . Ich empfehle dringend, ihre FAQ zu Best Practices zu lesen, da dies ziemlich pragmatisch ist.

TDD ist ein anderer Prozess zum Schreiben Ihrer Software. Die Grundvoraussetzung für Unit-Tests ist, dass Sie weniger Zeit im Debugger verbringen, um den Code zu durchlaufen, und schneller herausfinden, ob Ihre Codeänderung versehentlich etwas anderes im System beschädigt. Das passt zu TDD. Der TDD-Zyklus sieht folgendermaßen aus:

  1. Schreiben Sie einen Test
  2. Beobachten Sie, wie es fehlschlägt (beweisen Sie, dass Sie etwas zu tun haben)
  3. Schreiben Sie genau das, was für den Test erforderlich ist - nicht mehr.
  4. Schau es dir an (yay!)
  5. Refactor (besser machen)
  6. Waschen, spülen und wiederholen

Was beim Anwenden von TDD weniger offensichtlich ist, ist, dass die Art und Weise ändert, wie Sie Code schreiben . Indem Sie sich dazu zwingen, darüber nachzudenken, wie Sie testen/validieren können, ob der Code funktioniert, schreiben Sie testbaren Code. Und da es sich um Unit-Tests handelt, bedeutet dies normalerweise, dass Ihr Code modularer wird. Modularer und testbarer Code ist für mich ein großer Gewinn.

Müssen Sie jetzt Dinge wie C # -Eigenschaften testen? Stellen Sie sich eine Eigenschaft vor, die wie folgt definiert ist:

bool IsWorthTesting {get; set;}

Die Antwort wäre "Nein". Es lohnt sich nicht zu testen, da Sie zu diesem Zeitpunkt die Sprachfunktion testen. Vertraue einfach darauf, dass die C # -Plattform-Leute es richtig gemacht haben. Außerdem, wenn es fehlschlug, was könnten Sie tun, um es zu beheben?

Außerdem werden Sie feststellen, dass bestimmte Teile Ihres Codes zu aufwendig sind, um ordnungsgemäß getestet zu werden. Das heißt, tun Sie es nicht, aber stellen Sie sicher, dass Sie den Code testen, der das knifflige Problem verwendet/verwendet:

  • Überprüfte Ausnahmen, die nur auftreten können, wenn eine Installation fehlgeschlagen ist. Java hat eine Menge davon. Sie müssen einen catch-Block schreiben oder die aktivierte Ausnahme deklarieren, auch wenn es keine Möglichkeit gibt, dass sie fehlschlägt, ohne die installierten Dateien zu hacken.
  • Benutzeroberflächen. Das Finden des zu testenden Steuerelements und das Aufrufen der richtigen Ereignisse zur Simulation der Aktionen eines Benutzers sind sehr mühsam und in einigen Fällen unmöglich. Wenn Sie jedoch das Modell-/Ansichts-/Controller-Muster verwenden, können Sie sicherstellen, dass Ihr Modell und Ihre Controller getestet werden, und den Ansichtsteil manuellen Tests überlassen.
  • Client/Server-Interaktionen. Dies ist kein Komponententest mehr und jetzt ein Integrationstest . Schreiben Sie alle Teile, die zum Senden und Empfangen von Nachrichten über das Kabel erforderlich sind, aber nicht über das Kabel. Ein guter Ansatz besteht darin, die Verantwortung des Codes, der tatsächlich über die Leitung mit der Rohkommunikation kommuniziert, zu verringern. Verspotten Sie in Ihrem Unit-Test-Code das Kommunikationsobjekt, um sicherzustellen, dass sich die Dienste wie erwartet verhalten.

Ob Sie es glauben oder nicht, TDD hilft Ihnen dabei, in ein nachhaltiges Entwicklungstempo zu gelangen. Es liegt nicht an Magie, sondern daran, dass Sie eine enge Rückkopplungsschleife haben und in der Lage sind, wirklich dumme Fehler schnell zu erkennen. Die Kosten für die Behebung dieser Fehler sind im Wesentlichen konstant (zumindest für Planungszwecke ausreichend), da die kleinen Fehler niemals zu großen Fehlern werden. Vergleichen Sie dies mit der Burst-Natur von Code-Binge/Debug-Bereinigungs-Sprints.

33
Berin Loritsch

Sie müssen die Kosten für das Testen mit den Kosten für Fehler in Einklang bringen.

Das Schreiben eines 10-Zeilen-Unit-Tests für eine Funktion, die eine Datei öffnet, bei der der Fehler "Datei nicht gefunden" lautet, ist sinnlos.

Eine Funktion, die mit einer komplexen Datenstruktur etwas Komplexes macht - dann natürlich ja.

Das schwierige Stück liegt dazwischen. Denken Sie jedoch daran, dass der wahre Wert von Komponententests nicht die jeweilige Funktion testet, sondern die kniffligen Interaktionen zwischen ihnen. Ein Unit-Test, bei dem festgestellt wird, dass eine Änderung in einem Codebit eine Funktion in einem anderen Modul in 1000 Zeilen Entfernung unterbricht, ist im Kaffee sein Gewicht wert.

24
Martin Beckett

Testen ist Glücksspiel.

Das Erstellen eines Tests ist eine Wette, dass die Kosten für Fehler in einer Einheit, die auftreten und diese bei diesem Test nicht abfangen (jetzt und während aller zukünftigen Code-Revisionen), höher sind als die Kosten für die Entwicklung des Tests. Zu diesen Testentwicklungskosten gehören beispielsweise die Lohn- und Gehaltsabrechnung für zusätzliches Test-Engineering, die zusätzliche Markteinführungszeit, entgangene Opportunitätskosten, wenn andere Dinge nicht codiert werden usw.

Wie bei jeder Wette gewinnt man manchmal, manchmal verliert man.

Manchmal gewinnt späte Software mit weitaus weniger Fehlern gegen schnelles, aber fehlerhaftes Material, das zuerst auf den Markt kommt. Manchmal das Gegenteil. Sie müssen sich die Statistiken in Ihrem speziellen Bereich ansehen und wie viel Management spielen möchte.

Es ist möglicherweise so unwahrscheinlich, dass einige Arten von Fehlern auftreten oder dass sie aus frühen Gesundheitstests hervorgehen, dass sich die Zeit für die Erstellung zusätzlicher spezifischer Tests statistisch nicht lohnt. Aber manchmal sind die Kosten eines Fehlers so hoch (medizinisch, nuklear usw.), dass ein Unternehmen eine verlorene Wette abschließen muss (ähnlich wie beim Abschluss einer Versicherung). Viele Apps haben keine so hohen Ausfallkosten und benötigen daher keinen höheren unwirtschaftlichen Versicherungsschutz. Andere tun es.

23
hotpaw2

Mein Rat ist, nur den Code zu testen, mit dem Sie ordnungsgemäß arbeiten möchten.

Testen Sie nicht den Code, der fehlerhaft sein soll, und verursachen Sie später Probleme.

11
Nick Hodges

Ich frage mich oft, ob ich einen TDD-Ansatz ausprobieren sollte. Es klingt nach einer guten Idee, aber ich kann die zusätzliche Arbeit ehrlich gesagt nie rechtfertigen.

TDD und Unit Testing sind nicht dasselbe.

Sie können Code schreiben und später Komponententests hinzufügen. Das ist kein TDD und viel zusätzliche Arbeit.

TDD ist die Praxis des Codierens in einer Rotlichtschleife. Grünes Licht. Refactor-Iterationen.

Dies bedeutet, Tests für Code zu schreiben, der noch nicht vorhanden ist, die fehlgeschlagenen Tests zu beobachten, den Code zu korrigieren, damit die Tests funktionieren, und dann den Code "richtig" zu machen. Dies erspart Ihnen oft Arbeit

Einer der Vorteile von TDD besteht darin, dass weniger über Kleinigkeiten nachgedacht werden muss. Dinge wie Off-by-One-Fehler verschwinden. Sie müssen nicht die API-Dokumentation durchsuchen, um herauszufinden, ob die zurückgegebene Liste bei 0 oder 1 beginnt. Tun Sie es einfach.

8
Paul Butcher

Ich habe an einem System gearbeitet, bei dem wir fast alles getestet haben. Die bemerkenswerten Testausführungen waren der PDF und XLS-Ausgabecode.

Warum? Wir konnten die Teile testen, die die Daten gesammelt und das Modell erstellt haben, mit dem die Ausgabe erstellt wurde. Wir konnten auch die Teile testen, die herausgefunden haben, welche Teile des Modells in die Dateien PDF) gelangen. Wir konnten nicht testen, ob die PDF = sah in Ordnung aus, weil das völlig subjektiv war. Wir konnten nicht testen, ob alle Teile in einem PDF für einen typischer Benutzer lesbar waren, weil das auch subjektiv war Oder ob die Auswahl zwischen Balken- und Kreisdiagrammen für den Datensatz korrekt war.

Wenn die Ausgabe subjektiv sein soll, gibt es nur wenige Unit-Tests, bei denen Sie das tun können, was die Mühe wert ist.

3
sal

Für viele Dinge dauert ein "Schreiben-dann-manuell-Test" nicht länger als das Schreiben einiger Tests. Die Zeitersparnis ergibt sich aus der Möglichkeit, diese Tests jederzeit erneut auszuführen.

Denken Sie daran: Wenn Sie mit Ihren Tests eine anständige Funktionsabdeckung haben (nicht zu verwechseln mit der Codeabdeckung), und sagen wir, Sie haben 10 Funktionen - wenn Sie auf eine Schaltfläche klicken, haben Sie ungefähr 10 Sie wiederholen Ihre Tests ... während Sie sich zurücklehnen und Ihren Kaffee trinken.

Sie haben auch nicht , um die Minutae zu testen. Sie können Integrationstests schreiben, die Ihre Funktionen abdecken, wenn Sie nicht auf die Details eingehen möchten ... IMO, einige Komponententests testen die Sprache und Plattform zu genau und nicht den Code.

TL; DR Es ist wirklich nie angemessen , weil die Vorteile einfach zu gut sind.

2
Steven Evers

Zwei sehr gute Antworten, die mir begegnet sind, sind hier:

  1. Wann zum Unit-Test gegen manuellen Test
  2. Was ist beim Unit Testing nicht zu testen?

Die Rechtfertigungen zur Vermeidung von wahrgenommenem Overhead:

  • Sofortige Zeit-/Kostenersparnis für Ihr Unternehmen
  • Mögliche Zeit-/Kostenersparnis bei der Fehlerbehebung/Wartbarkeit/Erweiterung auf lange Sicht, auch wenn Sie weg sind.

Möchten Sie nicht ein großartiges Produkt von Ihrer Seite lassen, um die Qualität Ihrer Arbeit zu beweisen? Wenn Sie egoistisch sprechen, ist es nicht besser für Sie, dass Sie es tun?

2
Aditya P

Professionelle Entwickler schreiben Unit-Tests, weil sie langfristig Zeit sparen. Sie werden Ihren Code früher oder später testen, und wenn Sie dies nicht tun, werden Ihre Benutzer dies tun, und wenn Sie Fehler später beheben müssen, werden sie schwieriger zu beheben sein und mehr Auswirkungen haben.

Wenn Sie Code ohne Tests schreiben und keine Fehler haben, ist das in Ordnung. Ich glaube nicht, dass Sie ein nicht triviales System ohne Fehler schreiben können, also gehe ich davon aus, dass Sie es auf die eine oder andere Weise testen.

Unit-Tests sind auch wichtig, um Regressionen zu vermeiden, wenn Sie älteren Code ändern oder umgestalten. Sie nicht beweisen Ihre Änderung hat den alten Code nicht gebrochen, aber sie geben Ihnen viel Vertrauen (solange sie natürlich bestehen :))

Ich würde nicht zurückgehen und eine ganze Reihe von Tests für Code schreiben, den Sie bereits ausgeliefert haben, aber wenn Sie das nächste Mal eine Funktion ändern müssen, würde ich vorschlagen, Tests für dieses Modul oder diese Klasse zu schreiben, um eine Abdeckung von bis zu 70% zu erzielen. + bevor Sie Änderungen vornehmen. Sehen Sie, ob es Ihnen hilft.

Wenn Sie es versuchen und ehrlich sagen können, dass es keine Hilfe war, dann fair genug, aber ich denke, es gibt genug Beweise aus der Industrie, dass sie dazu beitragen, dass es sich zumindest lohnt, den Ansatz zu testen.

2
Steve

Es scheint, dass die meisten Antworten Pro-TDD sind, obwohl die Frage nicht nach TDD, sondern nach Unit-Tests im Allgemeinen gestellt wurde.

Es gibt keine völlig objektive Regel dahinter, was einem Unit-Test unterzogen werden soll oder nicht. Es gibt jedoch einige Fälle, in denen viele Programmierer anscheinend keinen Komponententest durchführen:

  1. Private Methoden

Abhängig von Ihrer OOP -Philosophie) können Sie private Methoden erstellen, um komplexe Routinen von Ihren öffentlichen Methoden zu entkoppeln. Öffentliche Methoden sollen normalerweise an vielen verschiedenen Orten aufgerufen und häufig verwendet werden, und die privaten Methoden sind es Nur wirklich von einer oder zwei öffentlichen Methoden in einer Klasse oder einem Modul aufgerufen, um etwas sehr Spezifisches zu erreichen. Normalerweise reicht es aus, Komponententests für öffentliche Methoden zu schreiben, nicht jedoch für die zugrunde liegenden privaten Methoden, die einen Teil der Magie bewirken. Wenn etwas schief geht Bei einer privaten Methode sollten Ihre Unit-Tests für öffentliche Methoden gut genug sein, um diese Probleme zu erkennen.

  1. Dinge, die Sie bereits wissen, sollten funktionieren (oder Dinge, die von jemand anderem getestet wurden)

Viele neue Programmierer widersprechen dem, wenn sie zum ersten Mal das Testen lernen, und denken, dass sie jede einzelne ausgeführte Zeile testen müssen. Wenn Sie eine externe Bibliothek verwenden und deren Funktionalität von den Autoren gut getestet und dokumentiert wurde, ist es normalerweise sinnlos, die spezifischen Funktionen in Komponententests zu testen. Beispielsweise könnte jemand einen Test schreiben, um sicherzustellen, dass sein ActiveRecord-Modell den korrekten Wert für ein Attribut mit einem Rückruf "before_save" an die Datenbank beibehält, obwohl dieses Verhalten selbst in Rails bereits gründlich getestet wurde. Die Methode (n), die der Rückruf möglicherweise aufruft, aber nicht das Rückrufverhalten selbst. Alle zugrunde liegenden Probleme mit importierten Bibliotheken sollten besser durch Abnahmetests als durch Komponententests aufgedeckt werden.

Beides kann zutreffen, unabhängig davon, ob Sie TDD durchführen oder nicht.

1
Ravenstine

Ken, ich und viele andere Entwickler sind im Laufe unserer Karriere mehrmals zu dem gleichen Ergebnis gekommen wie Sie.

Die Wahrheit, von der ich glaube, dass Sie sie finden werden (wie viele andere auch), ist, dass die anfängliche Investition in das Schreiben von Tests für Ihre Anwendung entmutigend erscheinen mag, aber wenn sie gut geschrieben und auf die richtigen Teile Ihres Codes ausgerichtet sind, können sie wirklich eine Menge sparen von Zeit.

Mein großes Problem war mit den verfügbaren Test-Frameworks. Ich hatte nie das Gefühl, dass sie das waren, wonach ich suchte, also habe ich einfach meine eigene, sehr einfache Lösung entwickelt. Es hat mir wirklich geholfen, mich auf die "dunkle Seite" der Regressionstests zu bringen. Ich werde einen grundlegenden Pseudo-Ausschnitt von dem teilen, was ich hier gemacht habe, und hoffentlich können Sie eine Lösung finden, die für Sie funktioniert.

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

Der einzige schwierige Teil danach ist herauszufinden, welche Granularitätsstufe Ihrer Meinung nach das beste "Bang for the Buck" für jedes Projekt ist, das Sie durchführen.

Das Erstellen eines Adressbuchs erfordert natürlich viel weniger Tests als eine Unternehmenssuchmaschine, aber die Grundlagen ändern sich nicht wirklich.

Viel Glück!

0
Adam Carstensen