it-swarm.com.de

Warum wird oft gesagt, dass die Testfälle erstellt werden müssen, bevor wir mit dem Codieren beginnen?

Warum wird oft gesagt, dass die Testfälle erstellt werden müssen, bevor wir mit dem Codieren beginnen?
Was sind ihre Vor- und Nachteile, wenn wir diesen Rat nicht hören?

Bezieht sich dieser Rat auf Black-Box-Tests oder White-Box-Tests oder beides?

34
Aquarius_Girl

Das Schreiben von Tests vor Implementierungen ist eine der Kernideen von Test Driven Development (TDD). Das Verfahren ist:

  • schreiben Sie einen fehlgeschlagenen Test
  • ändern Sie den Code, damit er erfolgreich ist, ohne einen anderen Test zu unterbrechen
  • refaktorieren Sie den Code und stellen Sie sicher, dass alle Tests noch bestanden sind

Diese Vorgehensweise ist unabhängig davon, ob Sie eine Funktion implementieren oder einen Fehler beheben. Es wird oft als "Rot-Grün-Refaktor" bezeichnet (rot = Test schlägt fehl, grün = Test besteht). Die Vorteile dieser Methode sind zahlreich:

  • der Test definiert klar, was "erledigt" bedeutet.
  • der Test dokumentiert, wie Sie den Code verwenden möchten
  • wenn Sie es richtig machen, erstellen Sie eine komplette Testsuite mit 100% Deckung als Nebenprodukt Ihres Entwicklungsprozesses. Das bedeutet, dass Sie immer zuverlässige Regressionstests zur Hand haben, egal was Sie tun
  • das Codieren, um einen Testfall (und nichts anderes) zu erfüllen, hilft Ihnen, sich auf eine Aufgabe zu konzentrieren, und verhindert das Kriechen von Funktionen
  • der Rot-Grün-Refaktor-Zyklus sorgt für einen schönen, sauberen und nachvollziehbaren Commit-Verlauf und passt gut zu einem Feature-Branch-Repository-Ansatz (jeder Feature-Branch beginnt mit einem Commit, das einen fehlgeschlagenen Test hinzufügt, und dann werden ein oder mehrere Commits ausgeführt, bis "grün" erreicht ist und dann ein oder mehrere Refactoring-Commits).
  • sie erstellen in regelmäßigen Abständen Arbeitsversionen - idealerweise endet jeder Rot-Grün-Refaktor-Zyklus mit einem potenziell versandfähigen Produkt, aber zumindest sollte es fehlerfrei erstellt werden und alle Tests bestehen.

Nun zu den Nachteilen:

  • Nicht jeder Code eignet sich für automatisierte Tests. Dies kann daran liegen, dass es sich um eine ältere Codebasis handelt, die ohne Berücksichtigung automatisierter Tests geschrieben wurde. es kann sein, dass die Problemdomäne so ist, dass bestimmte Dinge nicht verspottet werden können; oder Sie verlassen sich auf externe Datenquellen, die nicht unter Ihrer Kontrolle stehen und zu kompliziert wären, um sie zu verspotten; usw.
  • Manchmal sind Korrektheit, Wartbarkeit und Stabilität auf der Prioritätenliste nicht hoch genug. Das hört sich schlecht an, muss es aber nicht sein: Wenn Sie ein Einweg-Skript schreiben, um eine Reihe von Dokumenten stapelweise zu konvertieren, ist das Schreiben von Tests überhaupt albern - Sie führen es nur auf ein paar Testdokumenten aus Ergebnis, und das ist es. Automatisierte Tests würden hier keinen Mehrwert bringen.
  • Wenn Sie den Test vor dem Schreiben des Codes schreiben, wissen Sie bereits genau, was Sie tun möchten. Sehr oft jedoch nicht, und es ist eine erhebliche Menge an explorativer Programmierung erforderlich, um ein Gefühl für die jeweilige Problemdomäne zu bekommen. und meistens werden die Ergebnisse einer solchen explorativen Codierung dann in Form gebracht, um das eigentliche Produkt zu werden. Automatisierte Tests sind für solche Produkte genauso wertvoll, aber es macht wenig Sinn, sie hinzuzufügen, bevor Sie wissen, was Sie machen werden. In diesem Fall ist es besser, den Prototyp am Ende der Explorationsphase zu nehmen, Tests hinzuzufügen, um alles abzudecken, was Sie bisher haben, und von dort zu Rot-Grün-Refaktor zu wechseln.
  • Test vor der Implementierung ist nicht jedermanns Sache. Das erste Schreiben der Implementierung fühlt sich natürlicher an, und einige Leute haben es leichter, auf diese Weise in einen Fluss zu geraten
39
tdammers

Warum wird oft gesagt, dass die Testfälle erstellt werden müssen, bevor wir mit dem Codieren beginnen?

Es ist ein Grundprinzip von testgetriebene Entwicklung , aber keine allgemeine "Best Practice". Nicht jeder will oder muss TDD machen, obwohl seine Befürworter oft behaupten, dass jeder davon profitieren würde.

Was sind ihre Vor- und Nachteile, wenn wir diesen Rat nicht hören?

Der Vorteil besteht darin, dass Sie gezwungen sind, vor dem Schreiben über Ihren Code nachzudenken, bevor Sie ihn schreiben. Dies hat zwei Hauptvorteile: Es ist weniger wahrscheinlich, dass Sie Sonderfälle und Randbedingungen vergessen, und Ihr Code muss testbar sein und also modular. Ein weiterer wichtiger Vorteil: Sie wissen jederzeit, dass Ihr Code so funktioniert, wie Sie es sich vorgestellt haben.

Der Nachteil ist, dass dies dazu anregen kann, über Details auf niedriger Ebene nachzudenken und wichtige Designprobleme zu übersehen (dasselbe kann jedoch passieren, wenn Sie gerade mit dem Codieren beginnen). Außerdem ist das am einfachsten zu testende Design nicht unbedingt das beste (aber wahrscheinlich viel besser als eines, das aus Ad-hoc-Codierung hervorgegangen ist).

Natürlich stellt sich die Frage, ob TDD mehr Zeit spart als das Schreiben all dieser Unit-Test-Kosten. Ihre Befürworter behaupten dies sicherlich.

Bezieht sich dieser Rat außerdem auf Black-Box-Tests oder White-Box-Tests oder beides?

Normalerweise befasst sich TDD ausschließlich mit nit-Tests , bei denen es sich um White-Box-Tests handelt. Integrationstests müssen zusätzlich durchgeführt werden.

36

Wenn ich zuerst testen schreibe, geht es nicht viel darum, die korrekte Funktion meines Codes zu überprüfen, nicht wirklich um Black Box oder White Box) oder was auch immer im Zusammenhang mit Qualitätssicherung steht, und hier ist warum ...

Im Laufe der Jahre habe ich eine Fähigkeit geübt und verbessert, um das Management davon zu überzeugen, dass ich gute Tester brauche 1 , 2 ,  und dies reicht aus, um sicherzustellen, dass mein Code wie beabsichtigt funktioniert, ohne dass ich viel darüber nachdenken muss.

Der Hauptgrund, warum ich den Test zuerst bevorzuge, ist, dass ich besser verstehe, wie ich meinen Code so gestalte, dass er bequem zu verwenden ist. Ich kann mir nicht gut vorstellen, wie mein Modul von anderen Modulen verwendet wird, damit ich es zu kompliziert machen kann. Das wird mich später beißen und möglicherweise sogar eine Neugestaltung erfordern.

Dies ist ein Problem, egal ob ich ein Modul für mich selbst oder für eine andere Person codiere. Es ist ebenso schmerzhaft, die unbequeme Schnittstelle selbst zu verwenden und anderen Programmierern die Verwendung zu erklären.

(http://i.stack.imgur.com/JwlL8.jpg

"Test-first" -Ansatz bewahrt mich vor diesem Schmerz; Es erfordert keine Vorstellungskraft, sofort zu sehen, wie mein Modul verwendet wird, wenn es so oder so entworfen wird, und es macht es einfach, das bequemere auszuwählen.

Wenn ich ein Modul für eine andere Person codiere, muss ich nicht mehr schmerzhaft erklären, wie man es verwendet.

Schauen Sie, Code in this test zeigt, wie Sie dieses Modul verwenden sollten, und wenn Sie es ausführen, sehen Sie auch, welche Ergebnisse Sie erwarten sollten. Verwenden Sie eine andere Methode als in this test wäre ein Fehler. Jetzt geh weg und lass mich etwas Interessantes machen.

7
gnat

Es wird im Zusammenhang mit dem Üben von TDD / BDD gesagt, die - Design Methoden, keine Testmethoden.

Bei TDD/BDD besteht die Idee darin, die API-Nutzung vor dem Schreiben der API zu vertreiben und sie mit Tests weiterzuentwickeln.

In diesem Licht geht es darum, einen Test für einen nicht vorhandenen API-Aufruf oder einen Test für ein nicht vorhandenes API-Verhalten zu schreiben und ihn dann zu implementieren.

Beim Testen von Blackbox/Whitebox geht es wieder nicht um Testen - es geht um Design.

5
Oded

Warum wird oft gesagt, dass die Testfälle erstellt werden müssen, bevor wir mit dem Codieren beginnen?

Es gibt einige Gründe, warum dies gesagt wird.

  • Einige Leute nähern sich Tests (Blackbox) als Verträge. Dies zwingt die Person, die den Test schreibt, und die Person, die den Code implementiert, zu klaren Kriterien für den Erfolg. Dies bedeutet, dass Sie Code schreiben, um den Vertrag zu erfüllen, und so wissen Sie, wann die erforderliche Funktionalität erfüllt ist.
  • TDD (Test Driven Development) ist eine Praxis, bei der Sie die gesamte Entwicklung durch Tests vorantreiben. Klassischerweise erfolgt dies mit Komponententests, in jüngerer Zeit jedoch mit Tests auf jeder Ebene, die für Ihr Produkt und Ihren Prozess geeignet ist.

Was sind ihre Vor- und Nachteile, wenn wir diesen Rat nicht hören?

Vorteile

  • Vertreibt Unklarheiten zu einem früheren Zeitpunkt im Prozess, da Sie die Erfolgskriterien verstehen müssen, bevor Sie den Test schreiben.
  • Einige Befürworter schlagen vor, dass es speziell für TDD-Einheiten Designvorteile gibt, da es eine lose Kopplung und einen modulareren Design erzwingt.
  • Vertrauen, dass Ihr Code funktioniert (zumindest für die getesteten Teile).

Nachteile

  • Verstehen, wie wartbare Tests geschrieben werden.
  • Verstehe, wie man gute Tests schreibt.
  • Verstehen Sie, wann Sie den Kompromiss zwischen einem sehr teuren guten Test und einem kostengünstigen, weniger guten Test eingehen müssen.
  • Mehr Code zu pflegen

Bezieht sich dieser Rat außerdem auf Black-Box-Tests oder White-Box-Tests oder beides?

Es hängt davon ab, ob. Die meisten Komponententests sind eher Blackbox-Tests, da sie die Eingabe und Ausgabe der Methode oder Funktion untersuchen. Es gibt jedoch Zeiten, in denen Mocks oder Stubs erforderlich sind, was den Test eher zu einem Whitebox-Test macht, da jetzt Informationen zur Implementierung erforderlich sind. Dies kann für die Zwecke von TDD ein strittiger Punkt sein, da der Entwickler normalerweise derjenige ist, der die Tests schreibt.

3
dietbuddha