TDD ERSTE Prinzip

Ich bin nicht zu verstehen, wie die TDD ERSTE Prinzip nicht beachtet wird in dem folgenden code.

Dies sind meine Notizen über das ERSTE Prinzip:

Schnell: laufen (einige) tests schnell (seit Sie laufen die ganze Zeit)

Unabhängige: keine tests von anderen abhängen, so können beliebige Teilmenge in beliebiger Reihenfolge

Wiederholbare: run N Zeiten, gleiche Ergebnis (zum isolieren von Fehlern und ermöglichen die Automatisierung)

Selbstkontrolle: test kann automatisch erkennen, wenn bestanden (keine menschliche Kontrolle des Ausgangs)

Rechtzeitige: geschrieben etwa zur gleichen Zeit wie code under test (mit TDD, zuerst geschrieben!)

Die quiz-Frage:

Sally will Ihre website, um ein spezielles layout auf den ersten Dienstag jeden Monats. Sie hat die folgenden controller und test-code:
# HomeController
 def index
   if Time.now.tuesday?
     render 'special_index'
   else
     render 'index'
   end
 end

 # HomeControllerSpec
 it "should render special template on Tuesdays" do
   get 'index'
   if Time.now.tuesday?
     response.should render_template('special_index')
   else
     response.should render_template('index')
   end
 end
Was den ERSTEN Grundsatz nicht befolgt wird?

Schnell

Unabhängige

Wiederholbare

Selbstkontrolle

Rechtzeitige

Ich bin mir nicht sicher, das ERSTE Prinzip wird nicht eingehalten:

Schnell: Der code scheint zu sein, schnell, da ist nichts Komplex über seine tests.
Unabhängige: Der test hängt nicht von anderen Prüfungen.
Wiederholbare: Der test das gleiche Ergebnis erhalten, jedes mal. 'special_index' wenn es ist Dienstag und 'index' wenn es nicht Dienstag.
Selbstkontrolle: Der test kann automatisch erkennen, wenn es übergeben wird.
Rechtzeitige: Sowohl der code und test-code sind hier auf der gleichen Zeit.

Wählte ich Rechtzeitige auf das quiz, denn der test-code vorgestellt wurde, nachdem der controller-code. Aber ich hab die Frage falsch, und im Nachhinein war dies keine gute Wahl. Ich bin mir nicht sicher, das ERSTE Prinzip wird nicht gefolgt hier.

InformationsquelleAutor user86408 | 2013-08-02

tdd

34

Es ist nicht Repeatable wie nicht jeder Tag ist Dienstag 🙂 Wenn Sie diesen test ausführen, am Montag erhalten Sie ein Ergebnis, wenn man es am Dienstag, eine andere.
- Es wäre adhärenten, wenn es einen separaten test für jeden Tag der Woche, nicht wahr?
- Nein, es wäre adhärenten könnte man Spritzen, ein Datum, und stellen Sie sicher, dass Sie das richtige Tat, wenn er dachte, das ist was für ein Tag es ist. An diesem Punkt könnten Sie umfassend testen, alle auf einmal und unabhängig von dem aktuellen Datum, anstatt zu warten bis zu einer Woche und testen Sie jeden Tag.
InformationsquelleAutor Claudio Redi
0

Unabhängig und Wiederholbar

Nicht unabhängig von Datum und dann würde es ausführen können, wiederholen Sie aber technisch das gleiche Ergebnis erhalten, weil Sie wählen, um

Der richtige Weg, um einen test zu machen für den HomeController in Bezug auf ERSTE Konzept ist die Zeit zu ändern, bevor die Bewertungsphase
- Ich denke "Unabhängig" steht für: Abhängigkeiten zu anderen tests. Dies ist nicht der Fall in dem Beispiel.
InformationsquelleAutor windX
0

Ja, die Verwirrung ist teilweise der Grund dafür, dass die F. I. R. S. T.-Prinzip nicht vollständig oder präzise genug, was das "ich". In Kursen, die ich besuchte, das Prinzip hieß F. I. R. S. T.

Das zweite "I" steht für "Isoliert". Der test oben ist unabhängig von anderen tests, aber nicht isoliert in einer separaten Klasse oder Projekt.

[Aktualisiert]:

Isolation bedeuten kann:
- Einer unit-tests Isolate Funktionalität aus einem SUT (system unter test). Sie isolieren Funktionen auch aus einer einzigen Funktion. Dies zeichnet die Linie zwischen unit-tests und deren verwandten Komponenten-tests und integration-tests, und natürlich auch auf system-Prüfungen.
- "Tests isolieren Ausfälle. Ein Entwickler sollte nie müssen Sie ein reverse-Engineering-tests oder der code wird getestet, um zu wissen, was falsch gelaufen ist. Jede test-Klasse name und Prüfverfahren-Namen mit der text soll die Aussage genau angeben, was falsch ist und wo." Ref.: Geschichte der ERSTE Grundsatz
- Einen unit-test isoliert werden konnte aus dem SUT, die es tests in einem anderen Entwickler Artefakt (Klasse, Paket, Entwicklung, Projekt) und/oder die Lieferung Artefakt (Dll -, Paket -, Montage).
- Unit-tests, die Prüfung der gleichen SUT, vor allem Ihre mit Behauptet, sollte isoliert von einander in verschiedenen test-Funktionen, aber dies ist nur eine Empfehlung. Ideal in jeder unit-test enthält nur eine geltend machen.
- Unit-tests testen der verschiedenen SUTs, sollen voneinander isoliert werden oder aus anderen Arten von tests, die natürlich weiterhin in anderen Klassen oder anderen erwähnten Artefakte.
Unabhängigkeit bedeuten kann:
- Unit-tests sollten Sie sich nicht auf die jeweils anderen (expliziten Unabhängigkeit), mit Ausnahme der speziellen "setup" und "teardown" - Funktionen, aber auch das ist Thema für eine Diskussion.
- Insbesondere unit-tests sein sollte, um-unabhängig (implizite Unabhängigkeit). Das Ergebnis sollte nicht davon abhängen, unit-tests ausgeführt, bevor. Das klingt zwar trivial, ist es nicht. Es gibt tests, die kann nicht vermeiden, Initialisierungen und/oder ab-Laufzeiten. Nur eine freigegebene (z.B. Klassen -) Variablen und der SUT könnte anders reagieren, wenn es gestartet wurde, vor. Stellen Sie einen externen Anruf an das Betriebssystem? Einige dll wird geladen erste mal? Sie haben bereits eine potenzielle Abhängigkeit, zumindest auf OS-Ebene - manchmal nur Kleinigkeiten, die manchmal unerlässlich, um nicht entdecken zu einem Fehler. Es kann notwendig sein, um hinzuzufügen, cleanup-code, um zu erreichen optimale Unabhängigkeit der tests.
- Unit-tests sollte sein, die unabhängig sind, so viel wie möglich von der runtime-Umgebung und nicht abhängig von einer bestimmten test-Umgebung oder Umgebung. Das gehört auch zum Teil zu "Wiederholbar".
  Keine Notwendigkeit, fillout zwanzig Dialoge vor. Keine Notwendigkeit, den server zu starten. Keine Notwendigkeit, die Datenbank verfügbar machen. Keine Notwendigkeit für eine andere Komponente. Keine Notwendigkeit für ein Netzwerk. Um das zu erreichen, oft test doubles verwendet werden (stubs, verspottet, Fälschungen, Attrappen, Spione, ..).
  
  (Gerard Meszaros' klassisches Werk über: xUnit-Muster, hier prägen Sie den Namen 'test double" und der Definition der verschiedenen Arten von)
  
  (Test Doppel-zoo schnell erklärt)
  
  (Folgen Sie Martin Fowler 2007, darüber nachzudenken, stubs, mocks, etc. Classic)
- Während ein unit test ist nie völlig unabhängig von der SUT, es sollte im Idealfall unabhängig, so viel wie möglich von der aktuellen Umsetzung und nur verlassen sich auf die öffentliche Schnittstelle der Klasse oder Funktion getestet (SUT).
Fazit: In diesen Interpretationen das Wort "isolation", betont mehr den physischen Standort, die oft impliziert logische Unabhängigkeit zu einem gewissen Grad (z.B. Klasse Niveau isolation).

Keine Vollständigkeit bezüglich potenziell mehr Akzentuierungen und Bedeutungen behauptet.

Siehe auch Kommentare hier.

Aber es gibt noch mehr Eigenschaften von (guten) unit-tests: Roy Osherove fand einige weitere Attribute in seinem Buch "The art of unit testing", die ich nicht finden, genau in die F. I. R. S. T.-Prinzip (link zu seinem Buch Website), und die zitiert werden hier mit meinen eigenen Worten (und Abkürzung):
- Full Kontrolle von SUT: der unit-test sollte die volle Kontrolle über das SUT. Ich sehe das im Prinzip identisch wie die Unabhängigkeit von der test-und Laufzeit-Umgebung (z.B. mit mocks, etc.). Aber wegen der Unabhängigkeit ist so ambigous, macht es Sinn, verbringen Sie einen separaten Brief.
- Eineutomated (bezogen auf wiederholbare und selbst-Kontrolle, aber nicht das gleiche)
  identisch). Dies erfordert eine Prüfung (Läufer -) Infrastruktur.
- Rzuständige: Der test relevant sein sollte morgen. Dies ist eines der schwierigsten Anforderungen zu acchieve, und je nach "Schule" möglicherweise gibt es eine Notwendigkeit für temporäre unit-tests bei TDD auch. Wenn ein test ist nur die Prüfung der Verträge, das ist acchieved, aber das kann nicht genug für die hohe code-Abdeckung Anforderungen.
- Consistent Ergebnis: Effektiv ein Ergebnis von "genügend" Unabhängigkeit. Konsistenz ist, was einige Leute auch in "Wiederholbar". Es ist ein wesentlicher überlappung, aber Sie sind nicht identisch.
- Self-Erläuterung: In Bezug auf die Namensgebung, die Struktur des gesamten Tests, und speziell der syntax der assert-als Schlüssel Linie, es sollte klar sein, was geprüft wird, und was falsch sein könnte, wenn ein test fehlschlägt. Im Zusammenhang mit "Tests isolieren Fehler", siehe oben.
- Small, einfachen oder in seinen Worten: "einfach zu implementieren" (wieder, verwandt, aber nicht identisch). Oft im Zusammenhang mit "Schnell"
Angesichts all dieser spedific Punkte sollten es werden, mehr klar als vorher, es ist aber einfach zu schreiben (gut) unit-tests.
- würden nicht Isoliert gehören Independent? Zumindest ist das meine interpretation des Begriffs.
- Beide Begriffe scheinen zu bedeuten, etwas ähnlich, aber im detail gibt es eine Liste, was Sie bedeuten könnte für Sie. Isoliert bedeutet IMHO hier vor allem, dass 1. Unit-tests isolieren Funktionen, die idealerweise nur aus einem einzigen Behaupten, und durch keine Weise derselben als Integrations-oder Systemtest. 2. Unit-tests sind oft isoliert in einer eigenen Klasse oder auch Projekt - /Paket - /Montage, aber Sie zu isolieren aus dem SUT bedeutet nicht unbedingt, Sie sind wirklich unabhängig von der SUT, offensichtlich.
- Unabhängigkeit verstanden werden könnte oder gestresst sind offensichtlich unterschiedlich. Unabhängig von was? Vollständige Unabhängigkeit der Tests auf dem SUT? Nicht wirklich!!! Unabhängigkeit von der Implementierung des SUT (im Gegensatz zu der öffentlichen Schnittstelle)? Ja, das ist ein wichtiger Punkt der test-Strategie (und testen Lebensdauer), aber nicht alle unit-tests erfüllen. Unabhängigkeit ausführen, um andere tests ist einer der wichtigsten Punkte. Sehr kleinlich, isolation von tests, die von einander unabhängig von Ihrer Unabhängigkeit (insb. um die Unabhängigkeit) von einander 🙂
- Ok, sorry für den Witz. Ich meine, man kann Sie sammeln, Sie in einer Klasse oder gar in einer test-Funktion, das ist etwas anderes. Mehr Unabhängigkeit: Unabhängigkeit von der Umwelt ist eine wichtige Eigenschaft eines unit-test. Wenn Sie eine Datenbank benötigen oder eine Verbindung, eine web-site, es ist kein unit-test. Dies bezieht sich wieder auf "Repeatable", aber wieder nicht das gleiche bedeuten. Ok?
InformationsquelleAutor Philm

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.