Reflexionen zu TDD. Warum wird diese Methode nicht allgemein akzeptiert?

Ursprünglicher Autor: Doug Arcuri
  • Übersetzung
Hi, Habr!

Wir haben lange und praktisch erfolglos nach einem hellen Kopf gesucht, um Herrn Kent Beck auf den Markt zu drängen - das heißt, wir suchen jemanden, der bereit ist, ein Buch über uns zu schreiben. Mit echten Beispielen, einer Geschichte über die eigenen Zapfen und Erfolge. Es gibt sehr wenige Bücher zu diesem Thema, und Sie werden die Klassiker nicht bestreiten ... vielleicht haben wir uns deshalb noch nicht mit diesem Kopf getroffen.

Daher haben wir uns entschieden, nicht nur erneut daran zu erinnern, dass wir nach einer solchen Person suchen, sondern auch die Übersetzung eines ziemlich umstrittenen Artikels anzubieten, dessen Autor Doug Arcuri seine eigenen Gedanken darüber äußert, warum TDD nicht zum Mainstream geworden ist. Lassen Sie uns besprechen, ob er recht hat und wenn nicht, warum.



Dies ist kein einführender Testentwicklungskurs. Hier werde ich meine eigenen Ideen zum Neustart dieser Disziplin vorstellen und über die praktischen Schwierigkeiten des Unit-Tests sprechen.

Der legendäre Programmierer Kent Beck ist der Autor der TDD-Methode (Entwicklung durch Testen) im modernen Sinne. Kent beteiligte sich zusammen mit Erich Gammoy an der Entwicklung von JUnit, einem weit verbreiteten Test-Framework.

In seinem Buch erklärt XP (Second Edition) Kent beschreibt , wie an der Kreuzung der Werte und Praktiken bilden Prinzipien . Wenn Sie eine Liste von Konzepten erstellen und diese in eine Art Formel einsetzen, erhalten Sie eine Umwandlung.

[KISS, Quality, YAGNI, ...] + [Testing, Specs, ...] == [TDD, ...]

Ich respektiere diese Arbeit, die für Kent eine Frage des Lebens ist, nicht nur für die Meisterwerke, die er im Bereich der Programmierung geschaffen hat, sondern auch dafür, dass er unermüdlich das Wesen von Vertrauen , Mut , Effizienz , Einfachheit und Verwundbarkeit erforscht . All diese Eigenschaften erwiesen sich als unverzichtbar für die Erfindung der Extreme Programming (XP).

TDD ist ein Grundsatz und eine Disziplin , die in der XP-Community eingehalten werden. Diese Disziplin ist bereits 19 Jahre alt.

In diesem Artikel werde ich meine Meinung darüber teilen, wie viel TDD gelernt hat. Dann werde ich interessante persönliche Beobachtungen teilen, die mir während der Besetzung von TDD kamen. Zum Schluss versuche ich zu erklären, warum TDD nicht so viel ausgelöst hat, wie es schien. Lass uns gehen.

TDD, Forschung und Professionalität

Seit über 19 Jahren ist die TDD-Disziplin in der Programmierszene umstritten.
Die erste Frage, die ein professioneller Analyst an Sie stellt, lautet: "Wie viel Prozent der Entwickler, die heute TDD verwenden"? Wenn Sie einen Freund Robert Martin (Onkel Bob) und einen Freund Kent Beck danach gefragt haben, lautet die Antwort „100%“.

Nur Onkel Bob ist sicher, dass es unmöglich ist, sich als Profi zu bezeichnen, wenn Sie die Entwicklung nicht durch Testen üben .

Onkel Bob ist seit mehreren Jahren in diese Disziplin involviert, daher ist es selbstverständlich, dass er in diesem Testbericht darauf aufmerksam wird. Onkel Bob verteidigte TDD und erweiterte die Grenzen dieser Disziplin erheblich. Sie können sicher sein, dass ich sowohl vor Onkel Bob als auch vor seinem pragmatischen Dogmatismus höchsten Respekt habe.

Niemand stellt jedoch die folgende Frage: „Zu praktizieren bedeutet schließlich„ bewusst zu verwenden “- aber es lässt uns nicht zu, über den Prozentsatz zu urteilen, oder?“ Nach meiner subjektiven Meinung praktizierten die meisten Programmierer TDD nicht einmal für eine symbolische Zeit.

Die Realität ist, dass wir diese Zahlen wirklich nicht kennen, weil niemand diesen Prozentsatz aktiv untersucht hat. Alle spezifischen Daten sind auf eine kleine Auswahl von Unternehmen beschränkt, die auf der WeDoTDD- Website erfasst werden . Hier finden Sie Statistiken zu solchen Unternehmen, Interviews mit denjenigen, die ständig TDD praktizieren, aber diese Liste ist klein. Außerdem ist es unvollständig, da selbst eine einfache Suche andere große Organisationen, die an TDD beteiligt sind, anzeigt - aber möglicherweise nicht die volle Kapazität aufweist.

Wenn wir nicht wissen, wie viele Unternehmen TDD praktizieren, stellt sich folgende Frage: "Wie effektiv ist TDD, gemessen an seinen messbaren Vorteilen?"
Sie werden sich wahrscheinlich darüber freuen, dass im Laufe der Jahre eine Reihe von Studien durchgeführt wurde, die die Wirksamkeit von TDD bestätigen. Unter ihnen - sicherlich maßgebliche Berichte von Microsoft , IBM , der University of North Carolina und der University of Helsinki .



Ausdrucksvolles Diagramm aus dem Bericht der Universität Helsinki.

Bis zu einem gewissen Grad beweisen diese Berichte, dass die Fehlerdichte um 40 bis 60% reduziert werden kann, was intensivere Arbeit erfordert. während die Ausführungszeit um 15-35% zunimmt. Diese Zahlen zeigen sich bereits in Büchern und neuen industriellen Methoden, insbesondere in der DevOps-Community.

Wenn Sie diese Fragen teilweise beantworten, gehen Sie zum letzten: "Was kann ich erwarten, wenn ich anfange, TDD zu üben"? Für die Antwort auf ihn habe ich meine persönlichen Beobachtungen von TDD formuliert. Lass uns zu ihnen kommen.

1. TDD erfordert einen Verbalisierungsansatz:

Wenn wir TDD üben, beginnen wir, uns dem Phänomen der „Zielbestimmung“ zu stellen. Kurz gesagt: Kurze Projekte wie das Vorbereiten fehlgeschlagener und erfolgreicher Tests sind für Entwickler eine ernsthafte intellektuelle Herausforderung. Der Entwickler muss klar artikulieren: "Ich denke, dass dieser Test erfolgreich sein wird" und "Ich denke, dass dieser Test fehlschlagen wird" oder "Ich bin mir nicht sicher, ob ich darüber nachdenken möchte, nachdem ich diesen Ansatz ausprobiert habe."

IDE ist für die Entwickler der Gummiente geworden, die sich aktiv für ein Gespräch mit ihr einsetzt. In TDD-Unternehmen sollten Gespräche über einen solchen Plan mindestens zu einem ständigen Brummen führen.

Denken Sie zuerst nach - und machen Sie dann Ihren nächsten Schritt (oder Ihre nächsten Schritte).

Eine solche Verstärkung spielt eine Schlüsselrolle in der Kommunikation: Sie ermöglicht Ihnen nicht nur, den nächsten Schritt vorherzusagen, sondern auch dazu zu animieren, den einfachsten Code zu schreiben, der die Durchführung eines Unit-Tests gewährleistet. Wenn der Entwickler still bleibt, wird er natürlich vom Kurs abkommen, danach muss er in die Brunft zurückkehren.

2. TDD pumpt den Motorspeicher

Der Entwickler, der seinen ersten TDD-Zyklus durchläuft, wird schnell müde - weil dieser Prozess unbequem ist und ständig zum Erliegen kommt. Dies ist eine häufige Situation bei Aktivitäten, die eine Person nur beginnt, aber noch nicht beherrscht. Der Entwickler greift auf Abkürzungen zurück und versucht, diesen Zyklus zu optimieren, um sich einen Überblick zu verschaffen und den Motorspeicher zu verbessern.
Motorisches Gedächtnis ist unabdingbar für die Arbeit, Freude zu bereiten und lief wie am Schnürchen. In TDD ist dies wegen der Wiederholung von Aktionen notwendig.

Bringen Sie einen Spickzettel mit solchen Abkürzungen heraus. Lernen Sie die maximalen Tastenkombinationen in Ihrer IDE, um Ihre Loops effektiv zu machen. Dann schau weiter.

In nur wenigen Sitzungen beherrscht der Entwickler die Auswahl der Verknüpfungen perfekt. Insbesondere mehrere Sitzungen reichen aus, um einen Teststand aufzubauen und auszuführen. Wenn Sie üben, neue Artefakte zu erstellen, Text hervorzuheben und durch die IDE zu navigieren, wird Ihnen das alles natürlich vorkommen. Schließlich werden Sie zu einem echten Profi und erlernen alle Techniken des Refactorings: insbesondere Extraktion, Umbenennen, Generieren, Heben, Neuformatieren und Absteigen.

3. TDD erfordert zumindest ein wenig Nachdenken im Voraus.

Wenn ein Entwickler an TDD denkt, muss er eine kurze mentale Karte der Aufgaben berücksichtigen, die gelöst werden müssen. Beim traditionellen Programmieransatz ist eine solche Karte nicht immer der Fall, aber die Aufgabe selbst kann "auf Makroebene" präsentiert werden oder Forschungscharakter haben. Vielleicht weiß der Entwickler nicht, wie er das Problem lösen soll, sondern stellt sich das Ziel nur annähernd vor. Auf dem Weg zu diesem Ziel werden Komponententests vernachlässigt.

Setzen Sie sich zur Arbeit und beenden Sie das nächste "Sitzen" - versuchen Sie auch, daraus ein Ritual zu machen. Zuerst nachdenken und auflisten. Spiel damit. Eine andere Liste. Dann mach weiter, denk nach. Feiern Mehrmals wiederholen. Dann wieder nachdenken und aufhören.

Sei unnachgiebig in deiner Arbeit. Behalten Sie den Überblick über das, was gemacht wurde - setzen Sie einen Haken. Falten Sie niemals, bis es mindestens eine gibt. Denke nach!

Vielleicht wird der Wortlaut der Liste einige Zeit in Anspruch nehmen, die nicht in den Arbeitszyklus passt. Bevor Sie mit der Arbeit beginnen, sollten Sie jedoch eine Liste haben. Ohne sie wissen Sie nicht, wohin Sie gehen. Ohne Karte - nirgendwo.

// Список тестов
// "" -> не проходит
// "a" -> не проходит
// "aa" -> проходит
// "racecar" -> проходит
// "Racecar" -> проходит
// вывести валидацию
// отведать черничного эля

Der Entwickler muss eine Liste der von Kent Beck beschriebenen Tests erstellen . Mit der Testliste können Sie das Problem in Form von Zyklen lösen, die nahtlos ineinander übergehen. Über der Liste der Tests, die Sie ständig bearbeiten und aktualisieren müssen, auch einige Sekunden vor dem Start der Tests. Wenn die Testliste fast vollständig ohne die letzte Stufe durchlaufen wird, ist das Ergebnis „rot“ und der gesamte Test ist fehlgeschlagen.

4. TDD hängt von der Kommunikation mit Kollegen ab.

Nachdem die obige Liste abgeschlossen ist, können einige Schritte blockiert werden, da sie nicht genau beschrieben werden, was zu tun ist. Der Entwickler hat die Liste der Tests nicht verstanden. Das Gegenteil passiert auch - die Liste ist zu grob, in der es viele Annahmen über die noch nicht formulierten Anforderungen gibt. Wenn Sie so etwas bekommen, hören Sie einfach auf.

Wenn wir ohne TDD handeln, können wir redundante komplexe Implementierungen erhalten. Arbeit im Stil von TDD, aber gedankenlos, ohne Liste, nicht weniger gefährlich.

Wenn Sie feststellen, dass die Testliste Lücken aufweist, stehen Sie auf und sagen Sie es laut.

In TDD muss ein Entwickler verstehen, welches Produkt er ausführen soll, wobei er sich von den Vorstellungen der erforderlichen Anforderungen bei der Interpretation des Eigentümers leiten lässt - und nicht mehr. Wenn die Anforderung in diesem Zusammenhang unklar ist, fällt die Liste der Tests auseinander. Dieser Fehler muss diskutiert werden. Eine ruhige Diskussion hilft schnell, Vertrauen und Respekt aufzubauen. Außerdem werden auf diese Weise schnelle Rückkopplungszyklen gebildet.

5. TDD erfordert eine iterative Architektur

: In der ersten Ausgabe seines Buches über XP schlug Kent vor, dass Tests die treibende Kraft hinter der Architektur sein sollten. Im Laufe der Jahre sind jedoch Berichte darüber entstanden, wie Sprint-Teams in nur wenigen Sprints auf eine Mauer stoßen.

Natürlich ist der Aufbau einer auf Tests basierenden Architektur irrational. Onkel Bob selbst stimmte mit anderen Experten überein, dass dies nicht gut ist. Eine umfangreichere Karte ist erforderlich, jedoch nicht zu weit von den Testlisten entfernt, die Sie "im Feld" entwickelt haben.

Viele Jahre später brachte Kent diese These auch in seinem Buch TDD By Example zum Ausdruck . Wettbewerbsfähigkeit und Sicherheit sind zwei Hauptbereiche, in denen TDD nicht die treibende Kraft sein kann, und der Entwickler muss separat damit umgehen. Man kann sagen, dass Wettbewerbsfähigkeit eine andere Ebene des Systemdesigns ist. Die Wettbewerbsfähigkeit muss durch Iterationen entwickelt werden, wobei dieser Prozess mit TDD koordiniert wird. Dies gilt insbesondere heute, da sich einige Architekturen hin entwickelnreaktives Paradigma und reaktive Expansionen ( Reaktivität ist Wettbewerb im Zenit).

Erstellen Sie eine größere Karte der gesamten Organisation. Helfen, die Dinge ein bisschen in der Perspektive zu sehen. Stellen Sie sicher, dass Sie und das Team auf dem gleichen Kurs sind.

Die Idee , das gesamte System zu organisieren , ist jedoch am wichtigsten , und es wird keine TDD-Organisation bereitgestellt. Der Punkt ist, dass Komponententests eine einfache Sache sind. Iterative Architektur und TDD-Orchestrierung sind in der Praxis komplex und erfordern Vertrauen zwischen allen Teammitgliedern, Paarprogrammierung und solide Codeüberprüfungen. Es ist nicht ganz klar, wie dies zu erreichen ist, aber bald können Sie sicher sein, dass kurze Entwurfssitzungen im Einklang mit der Implementierung von Testlisten im Themenbereich durchgeführt werden sollten.

6. TDD zeigt die Fragilität von Komponententests und eine degenerierte Implementierung

. Komponententests haben eine Spaß-Eigenschaft, und TDD zeigt sie vollständig. Sie erlauben nicht, die Richtigkeit zu beweisen. E. V. Dijkstra arbeitete an diesem Problem und diskutierte, wie mathematische Beweise in unserem Fall möglich sind, um diese Lücke zu füllen.

Im folgenden Beispiel werden beispielsweise alle Tests gelöst, die sich auf ein hypothetisches unvollkommenes Palindrom beziehen, das von der Geschäftslogik diktiert wird. Die Probe wurde unter Verwendung der TDD-Methodik entwickelt.

// Не несовершенный палиндром@Testfun `Given "", then it does not validate`() {
    "".validate().shouldBeFalse()
}
@Testfun `Given "a", then it does not validate`() {
    "a".validate().shouldBeFalse()
}
@Testfun `Given "aa", then it validates`() {
    "aa".validate().shouldBeTrue()
}
@Testfun `Given "abba", then it validates`() {
    "abba".validate().shouldBeTrue()
}
@Testfun `Given "racecar", then it validates`() {
    "racecar".validate().shouldBeTrue()
}
@Testfun `Given "Racecar", then it validates`() {
    "Racecar".validate().shouldBeTrue()
}

Tatsächlich gibt es Mängel in diesen Tests. Unit-Tests sind selbst in den meisten trivialen Fällen fragil. Es ist niemals möglich, ihre Korrektheit zu beweisen, denn wenn wir es versuchen würden, würde dies eine unglaubliche geistige Arbeit erfordern, und die dazu erforderlichen Eingaben wären unmöglich vorstellbar.

// Слишком обобщенная реализация, сделанная на основе предоставленных тестовfun String.validate() = if (isEmpty() || length == 1) falseelse toLowerCase() == toLowerCase().reversed()
// Это наилучшая реализация, решающая все тестыfun String.validate() = length > 1
length > 1

length > 1kann als degenerierte Implementierung bezeichnet werden . Es reicht völlig aus, um das Problem zu lösen, aber es berichtet nichts über das Problem, das wir zu lösen versuchen.

Die Frage ist - wann sollte ein Entwickler aufhören, Tests zu schreiben? Die Antwort scheint einfach zu sein: Wenn es aus Sicht der Geschäftslogik ausreicht , und nicht nach Ansicht des Autors des Codes. Dies kann unserer Design-Leidenschaft schaden , und Einfachheit kann jemanden schlagen . Diese Gefühle werden durch die Befriedigung kompensiert, Ihren eigenen sauberen Code zu sehen und zu verstehen, dass der Code später mit Vertrauen umgestaltet werden kann. Der gesamte Code wird sehr ordentlich sein.

Beachten Sie, dass für die Unzuverlässigkeit von Komponententests erforderlich ist. Verstehen Sie ihre Stärken und Schwächen. Wenn sich das Gesamtbild nicht summiert, kann diese Lücke möglicherweise den Mutationstest ausfüllen .

TDD hat seine eigenen Vorteile, aber diese Methode kann uns dazu bringen, unnötige Sandburgen zu bauen. Ja, das ist eine Einschränkung , aber dank dieser Funktion können Sie schneller, weiter und zuverlässiger fahren. Vielleicht hatte Onkel Bob das vor Augen, als er beschrieb, was es aus seiner Sicht bedeutet , ein Profi zu sein .

Aber! Egal wie fragil die Unit-Tests aussehen mögen, sie sind eine absolute Notwendigkeit. Sie wandeln Angst in Mut. Tests bieten eine sanfte Code-Umgestaltung. Darüber hinaus können sie als Anleitung und Dokumentation für jeden neuen Entwickler dienen, der sich sofort einarbeiten und zum Nutzen des Projekts arbeiten kann - sofern dieses Projekt gut mit Komponententests abgedeckt ist.

7. TDD stellt den umgekehrten Zyklus von Testassertierungen dar.

Lassen Sie uns einen weiteren Schritt nach vorne machen. Um die folgenden zwei Phänomene zu verstehen, untersuchen Sie seltsame wiederkehrende Ereignisse. Lassen Sie uns zunächst einen kurzen Blick auf FizzBuzz werfen. Hier ist unsere Liste der Tests.

// Вывести числа от 9 до 15. [OK]// Для чисел, кратных 3, вывести Fizz вместо числа.// ...

Ging ein paar Schritte vorwärts. Nun scheitert unser Test.

@Testfun `Given numbers, replace those divisible by 3 with "Fizz"`() {
    val machine = FizzBuzz()
    assertEquals(machine.print(), "?")
}
classFizzBuzz{
    funprint(): String {
        var output = ""for (i in9..15) {
            output += if (i % 3 == 0) {
                "Fizz "
            } else"${i} "
        }
        return output.trim()
    }
}
Expected <Fizz 1011 Fizz 1314 Fizz>, actual <?>.

Wenn Sie die erwarteten Datenanweisungen in kopieren assertEquals, wird das gewünschte Ergebnis erzielt und der Test wird durchgeführt.

In manchen Fällen liefern fehlerhafte Tests das korrekte Ergebnis, um den Test zu bestehen. Ich weiß nicht, wie ich solche Ereignisse nennen soll ... vielleicht Voodoo-Test . Wie oft Sie dies feststellen, hängt zum Teil von Ihrer Faulheit und Ihren Verhaltensweisen beim Testen ab. Ich habe jedoch oft solche Dinge bemerkt, wenn eine Person versucht, eine Implementierung zu erhalten, die normalerweise mit vorgefertigten und vorhersagbaren Datensätzen funktioniert.

8. TDD demonstriert den Übergangsprioritätszustand

TDD kann dich fangen. Es kommt vor, dass der Entwickler in den handgefertigten Transformationen verwirrt ist, die er verwendet, um die gewünschte Implementierung zu erreichen. Irgendwann wird aus dem Testcode ein Engpass, in den wir rutschen.

Es entsteht eine Sackgasse . Der Entwickler muss sich zurückziehen und entwaffnen, indem er einige Tests entfernt, um diese Falle zu verlassen. Entwickler bleibt ungeschützt.

Wahrscheinlich geriet Onkel Bob über die Jahre seiner Karriere in solche Sackgassen, woraufhin ihm offenbar klar wurde, dass die Prüfung zwar bestanden werden musste, aber die richtige Reihenfolge der Maßnahmen festgelegt werden musste, um die Gefahr einer Sackgasse zu minimieren. Außerdem musste er einen anderen Zustand erkennen. Je spezifischer die Tests werden, desto verallgemeinerter wird der Code .



Die Reihenfolge der Konvertierungen. Sie sollten immer nach der einfachsten Option (am Anfang der Liste) suchen.

Dies ist die Vorbedingung der Transformationen . Anscheinend gibt es eine gewisse Reihenfolge des Refactoring-Risikos, zu dem wir nach bestandenem Test bereit sind. In der Regel ist es am besten, die Transformationsoption zu wählen, die ganz oben in der Liste angezeigt wird (die einfachste). In diesem Fall bleibt die Wahrscheinlichkeit, in eine Sackgasse zu geraten, minimal.

TPP oder sozusagen Uncle Bobs Testanalyse ist eines der faszinierendsten, technologischsten und aufregendsten Phänomene, die derzeit beobachtet werden.

Lassen Sie sich davon leiten, damit Ihr Code so einfach wie möglich ist.
Drucken Sie die TPP-Liste aus und legen Sie sie auf Ihrem Schreibtisch ab. Erkundigen Sie sich bei ihm, dass er nicht in eine Sackgasse gerät. Nehmen Sie in der Regel an: Die Reihenfolge sollte einfach sein.

Damit ist die Geschichte meiner wichtigsten Beobachtungen abgeschlossen. Im letzten Teil des Artikels möchte ich jedoch auf die Frage zurückkommen, die wir zu Beginn vergessen haben: "Wie viel Prozent der professionellen Programmierer verwenden heute TDD?". Ich würde antworten: "Ich glaube, es gibt wenige von ihnen." Ich möchte diese Frage weiter unten erläutern und versuchen zu erklären, warum.

Ist TDD in der Praxis fixiert?

Leider gibt es keine. Subjektiv scheint es, dass der Prozentsatz seiner Unterstützer gering ist, und ich suche weiter nach Daten. Meine Erfahrung im Recruiting, im Teammanagement und in der Selbstentwicklung (die mich fasziniert) erlaubt mir folgende Beobachtungen zu machen.

Grund 1: Unzureichender Kontakt mit der echten Testkultur:

Ich kann vernünftigerweise davon ausgehen, dass die meisten Entwickler nicht die Möglichkeit hatten, in einer echten Testkultur zu lernen und zu arbeiten.

Eine Testkultur ist eine Umgebung, in der Entwickler die Testkunst bewusst üben und verbessern. Trainieren Sie ständig Kollegen, die noch keine Erfahrung auf diesem Gebiet haben. In jedem Paar und mit jeder Pull-Anfrage wurde ein Feedback erstellt, das allen Teilnehmern dabei hilft, Testfähigkeiten zu entwickeln. Darüber hinaus gibt es in der gesamten Hierarchie der Ingenieure eine starke Unterstützung und ein Gefühl von Elbow. Alle Manager verstehen das Wesentliche des Testens und glauben daran. Wenn die Fristen sich zuspitzen, wird die Testdisziplin nicht verworfen, sie folgt jedoch weiterhin.

Diejenigen, die das Glück hatten, mich in einer solchen Testkultur zu testen, wie ich zum Beispiel die Gelegenheit hatte, solche Beobachtungen anzustellen. Diese Erfahrung wird uns bei neuen Projekten nützlich sein.

Grund 2: Mangel an Bildungsressourcen

Es wurde bereits versucht, Bücher zu TDD zu schreiben, z. B. xUnit Patterns und Effective Unit Testing . Offenbar gibt es jedoch immer noch keine Quelle, in der beschrieben wird, was getestet werden sollte und warum. In den meisten verfügbaren Quellen ist es nicht möglich, die vollständige Aussagekraft von Testaussagen und deren Überprüfung eindeutig zu vermitteln.

Auch bei Open-Air-Projekten ist das bei guten Unit-Tests dicht. Bei solchen ungewohnten Projekten schaue ich zuerst und was ist mit den Tests. Fast sicher erwartet mich eine Enttäuschung. Darüber hinaus kann ich mich an ein paar erfreuliche Fälle erinnern, in denen die Tests nicht nur vorhanden, sondern ... lesbar sind.

Grund 3: Das Thema wird an den Universitäten vernachlässigt, und ich habe

festgestellt, dass unter Bewerbern, die kürzlich ihren Abschluss gemacht haben, kaum jemand an strenge und disziplinierte Tests gewöhnt ist. Fast alle Entwickler, die ich kenne, haben das Testen nach dem Studium gelernt. jemand für sich, andere - gewöhnt an ein Unternehmen mit einer entwickelten Testkultur.

Grund 4: Eine starke Leidenschaft für Tests und der Wunsch, daran zu arbeiten, sind erforderlich.

Sie benötigen außerdem eine bekannte Sicherung, um sich für das Testen zu interessieren, um die Details von TDD und dessen Vorteile langfristig zu verstehen. Wir brauchen Unersättlichkeit und Sehnsucht nach einem sauberen Code, um unsere Kunst zu verbessern.

Für die meisten reicht es aus, alles zum Laufen zu bringen, und dies ist nur die halbe Geschichte von Kent Becks These: "Zuerst die Arbeit machen, dann richtig machen." Ich betone: Um zu erreichen, dass "alles funktioniert", heißt es bereits, einen ernsthaften Sieg zu erringen.

Es ist ebenso schwierig zu lernen, wie man Qualitätstests durchführt. Lassen Sie uns diese Idee in der Schlussfolgerung diskutieren.

Fazit

Die XP-Formulierung von Kent ist eine einfache Kombination aus Instinkt , Denken und Erfahrung.. Diese drei Stufen sind Schritte zum Erreichen des als Schwellenwert definierten Qualitätsniveaus. Dieses Modell erklärt das Problem mit TDD perfekt.

Die Schwelle für einen sauberen Testlauf ist hoch, sodass überschattet wird, wie hoch der Erfahrungsschatz ist, um diese Schwelle zu überwinden. Die meisten Spezialisten werden in der folgenden Abbildung niemals „auftauchen“, und diejenigen, die dies tun können, werden dies dank der seltenen Erfahrung, die in einer entwickelten Testkultur erworben wurde.



Aus dem Buch XP erklärt. Anfänglich verdeutlichte dieses Schema die Qualität des Designs. Stellen Sie sich also vor, dass der Schwellenwert noch höher ist.

Es ist ziemlich schwierig, Computerprogramme zu erstellen und zu organisieren, aber das Testen öffnet wirklich Ihre Augen für diese Arbeit.

Anfangs hatte ich das Gefühl, dass das Testen eine wichtige Sache ist, aber später sammelte ich Erfahrungen in der Testkultur. Ich habe während meiner gesamten Karriere über viele Jahre nachgedacht, aber ohne Erfahrung in einer entwickelten Testkultur wäre ich nicht über den Schwellenwert gestiegen.

Ich glaube, dass diese Idee von vielen anderen Entwicklern besucht wurde, aber sie konnten die wahren Vorteile der Testkultur nicht einschätzen, da sie keine spezifische Erfahrung hatten.

Die TDD-Disziplin ist zum Teil nicht „aufgeflogen“, weil die Lernkurve der Testkunst sehr steil ist. TDD erfordert trotz jahrelanger Erfahrung und Erfahrung im Testen eine einzigartige und nicht triviale Mentalität. Aber versuchen Sie es doch bei TDD.

Ich betone. TDD erfordert all diese Gedanken und Erfahrungen und mehr. TDD ist eine Fertigkeit und außerdem keine einfache. Ich denke schon, da TDD vom Entwickler verlangt, dass er konstant und stetig maximale Leistung bringt. Wir sind alle verwundbar, und nur wenige Entwickler arbeiten gerne unter solchen Bedingungen.

@Testfun `Given software, when we build, then we expect tests`() {
    build(software) shoudHave tests
}

TDD ist jedoch eine faszinierende Disziplin und ein Werkzeug, auf das man sich verlassen kann . Seine Phänomene sollten im Detail untersucht werden. Wie dem auch sei, diese Disziplin hilft dem Entwickler, sich zu verbessern, und in der Praxis verstärkt er nicht nur den einzelnen Entwickler, sondern das gesamte Team.

Jetzt auch beliebt: