Zum einen sitze ich fast nie nur da und schreibe Unit-Tests. Unit Tests sind Mittel zum Zweck, kein Selbstzweck. Sie sind eine Möglichkeit zu beantworten, "ob dieser Code die Grundaufgabe erfüllt, die er erfüllen soll".
Zum Beispiel schreiben einige Leute eine Funktion und öffnen dann eine interaktive Sitzung, um sie an einigen Werten zu testen und sicherzustellen, dass sie funktioniert:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
Aber jetzt entdeckst du einen Fehler:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
So beheben Sie es:
def fact x
if x < 0
raise "Can't take the factorial of a negative number"
elsif x == 0
1
else
x * fact(x-1)
end
end
>> fact -1
RuntimeError: Can't take the factorial of a negative number
from (irb):3:in `fact'
from (irb):10
Aber jetzt solltest du wirklich testen, ob es noch funktioniert:
>> fact 10
=> 3628800
>> fact 7
=> 5040
Wie Sie sehen, wiederholen Sie immer wieder dieselben Tests ... und müssen die Ergebnisse visuell vergleichen. Unit-Tests vermeiden in diesem Fall die Wiederholung. Es reduziert den Arbeitsaufwand. Und obwohl dies ein albernes kleines Beispiel ist, wird es in der realen Welt immer wichtiger und es wird immer schwieriger, manuell zu testen. Dies bedeutet natürlich, dass die einzelnen Komponenten einfach nicht getestet werden. Sie testen nur das gesamte Programm. Aber dann tauchen Käfer auf und sie sind viel schwerer zu finden. Oder es treten Fehler auf und sie sind behoben, aber jemand führt den gleichen Fehler erneut ein, weil niemand einen Testfall hinzugefügt hat, um sicherzustellen, dass dies nicht passiert ist. Oder jemand schaut sich ein großes Stück Code an und sagt: "Ich habe keine Ahnung, was dies tun soll, da es nicht dokumentiert ist und keine Tests hat ... Wenn ich diesen Fehler behebe, habe ich keine Ahnung, ob ich abhängig davon etwas anderes kaputt mache. Vielleicht schreibe ich das einfach von Grund auf neu. "
Unit-Tests reduzieren in diesen Fällen den gesamten Mehraufwand. Der beste Weg, ihnen Spaß zu machen, besteht darin, sicherzustellen, dass die Leute alle Arbeiten verstehen, die sie ersetzen, und die zusätzliche Flexibilität, die sich daraus ergibt, dass sie wissen, was jeder Code tun soll. Bis zu einem gewissen Grad müssen die Benutzer etwas mehr Erfahrung mit dem Schreiben und Verwalten einer großen Codebasis haben, um zu verstehen, wie wichtig Unit-Tests sein können. Wenn all ihr Code etwas ist, das sie einmal geschrieben und weggeworfen haben, werden sie ihn nie richtig verstehen.
Und Unit-Tests sollten nicht nachträglich geschrieben werden, da ein zusätzlicher Aufwand entsteht, sobald Sie Code haben, von dem Sie "wissen", dass er bereits funktioniert. Unit-Tests sollten zuerst oder zumindest (da Sie manchmal vergessen, sie zuerst zu schreiben) direkt nach dem Schreiben des fraglichen Codes geschrieben werden. Dies wird als testgetriebene Entwicklung bezeichnet und kann dazu beitragen, Ihre APIs zu verbessern. Wenn Sie zuerst die Tests schreiben, die die APIs testen, werden Sie lernen, wo die APIs zu verwenden sind, bevor Sie überhaupt den Code schreiben, und können viel einfacher umgestalten, als wenn Sie die Tests erst danach hinzufügen.
MbUnitBibliothek hat mein Leben verändert. Autotests sind wichtig. Automatisches Testen spart Zeit. Automatisches Testen spart Geld. Selbsttests können Leben retten. Autotests sind der einzige Weg. Autotests sind ein weiteres Sicherheitsnetz. Wenn ich einer von 50 Menschen bin, die an einer riesigen Architektur arbeiten, fühle ich mich wie ein weiterer Stein in einer Mauer. Mit Unit-Tests habe ich die Kontrolle.