Beste Antwort
Ich arbeite derzeit für AutoTrader, der dies meiner Meinung nach sehr gut macht.
Wir setzen Sie einfach vor einen Laptop mit größerem Monitor und Tastatur / Maus, paaren uns mit einem unserer leitenden Entwickler und beobachten ihn von einem anderen leitenden Entwickler.
Es macht ziemlich viel Spaß Alle, abgesehen von den üblichen Interviewnerven und der Tatsache, dass Sie neue Leute kennenlernen. Aber natürlich, wenn ich Ihr Paar bin, versuche ich, ein bisschen freundschaftliches Verhältnis zu haben, damit Sie sich willkommen fühlen und so weiter. Genau wie ich es normalerweise tun würde. Ich möchte, dass Sie erfolgreich sind.
Sie erhalten eine halbseitige Problembeschreibung einer einfachen Aufgabe. Und dann programmieren Sie ein paar Paare.
Es werden verschiedene Dinge beobachtet und bewertet:
- Schreiben Sie zuerst Tests? Nach dem Code? Niemals?
- Verwenden Sie Tests, um über das Design nachzudenken?
- Benennen Sie die Dinge klar?
- Bevorzugen Sie OOP, prozedurale Programmierung – oder nur einen enorme Funktion?
- Interagierst du gut mit dem Paar? Oder überhaupt?
- Erklären Sie Ihr Denken im Laufe der Zeit und laden Sie das Paar ein, einen Beitrag zu leisten? Oder schweigen Sie?
- Verwenden Sie Standardfunktionen in Java wie Sammlungen? Wenn nicht, was machen Sie?
- Verwenden Sie die IDE (die Ihrer Wahl entspricht) gut?
- Teilen Sie das Problem gut auf? Schlecht? Überhaupt nicht?
Wenn Sie Java, TDD und / oder Design als Unit-Test ausführen können und als einigermaßen sympathische Sorte erscheinen, erzielen Sie in der Regel hohe Punktzahlen.
Bei diesem Test geht es nicht um seltsame Sprachkenntnisse oder seltsame Algorithmuskenntnisse oder sogar darum, das Problem zu lösen.
Es geht darum zu sehen, wie Sie diese Dinge, die Sie in Ihrem Lebenslauf geschrieben haben, im wirklichen Leben verwenden.
Sie werden es wirklich genießen. Es gibt jedem ein faires Bild davon, wo sich ein Kandidat befindet.
Es spült auch rücksichtslos falsche CV-Ansprüche aus.
Sagen Sie, Sie machen TDD? Sie wissen nicht, was „behaupten“ bedeutet? Ach je. Angenommen, Sie haben OOP gemeistert? Der gesamte Code, der nicht funktioniert, entspricht der von uns gelieferten Komponententest. Oh je.
(Und ja, das ist wirklich passiert).
Für mich war es ein Augenöffner, auf beiden Seiten dieses Prozesses zu stehen.
Antwort
TDD ist ein Werkzeug. Was falsch ist, ist, dass TDD als Religion behandelt.
TDD wird normalerweise mit Komponententests durchgeführt: Tests kleiner Teile oder Funktionen („Einheiten“) ) Ihres Codes. Die Komponententests sollen schnell ausführen. Sie verspotten also im Allgemeinen alle externen Dienstabhängigkeiten und stellen nur sicher, dass der Code selbst getestet wird.
Das Problem mit riesigen Elefanten im Raum besteht darin, dass die von Ihnen verspotteten externen Dienste manchmal den größten Teil der Logik einer Funktion enthalten. Wenn Ihre „Einheit“ mithilfe einer Abfrage ein Element aus einer Datenbank abruft und es zurückgibt, verspottet , dass die Interaktion zu 100\% nutzlos ist außer als Ersatz für die Typprüfung.
Lassen Sie mich das noch einmal anders sagen: Die sogenannten „Vordenker“ ”, Die das Evangelium von TDD predigen, predigen auch häufig das Evangelium der dynamischen Sprachen. Die Sprachen, die sie Ihnen sagen, sind also so viel produktiver Tatsächlich erfordert das Testen viel mehr Arbeit und häufig das erneute Schreiben dieser Tests, wenn Sie eine Umgestaltung vornehmen müssen.
Schreiben Sie Ihren Code in einer sichereren Sprache wie C #, Java oder TypeScript, und Sie tun es nicht. Sie müssen sich keine Gedanken darüber machen, ob die Typen noch gültig sind. Und es gibt Tonnen tatsächliche Vorteile durch die Verwendung statischer Typsprachen, zusätzlich dazu, dass keine Tests geschrieben werden müssen, die eigentlich nichts testen.
Was meine ich also wirklich mit den Tests „nichts testen“? Angenommen, Sie haben eine Funktion, die eine SQL-Abfrage für Ihre Datenbank durchführt. Es soll nach Elementen suchen, die nach einem bestimmten Feld gefiltert sind. Um einen schnellen Komponententest zu schreiben, verspotten Sie die SQL-Abfrage. Sofern Ihre Scheinbibliothek nicht die gesamte Logik von PostgreSQL simulieren kann, die an einem Beispieldatensatz arbeitet, wird die eigentliche Logik Ihrer Funktion überhaupt nicht getestet ;; Die einzigen inhaltlichen Tests, die Sie schreiben konnten, um die Logik zu überprüfen, bestätigten nur, dass Ihre Mocks entsprechende Antworten zurückgaben.
Ich sehe häufig Mocks, die dies tun „Überprüfen Sie einfach, ob die Datenbank die richtige Anzahl von Malen aufgerufen wurde.“ Das würde Ihnen schließlich Ihre 100\% ige Codeabdeckung bringen! Großartig, eine Zahl, die die nicht-technischen Manager beeindruckt und in der Praxis absolut nichts bedeutet! Gehen Sie zu Team Deceptive Statistics!
Nein, Sie benötigen Systemtests oder Integrations- / E2E-Tests, um zu überprüfen, ob Ihr gesamtes System funktioniert Arbeiten. Nicht nur Komponententests, sondern auch Tests, bei denen die Aufrufe der Datenbank nicht verspottet, sondern diese Aufrufe stattdessen ausführt.Und wenn eine Testsuite eine tatsächliche Testdatenbank aufbauen, löschen und zwischen den Tests einfügen muss, ist TDD in der Praxis unpraktisch. Es ist zu langsam.
Schreiben Sie also zuerst den Code und dann Ihren E2E-Test, um sicherzustellen, dass das richtige Ergebnis erzielt wird. Sie können die Snapshot-Funktion von Testsuiten wie Jesthttps: //jestjs.io/docs/en/snapshot-testing verwenden, um nur zu überprüfen, ob sich die Antwort nicht ändert. Sieh es dir einmal an, um sicherzustellen, dass es korrekt ist. Nachdem du Jest mitgeteilt hast, dass es richtig ist, wird überprüft, ob es in zukünftigen Läufen gleich bleibt. APIs können nahezu automatisiert getestet und ihre Tests aktualisiert werden!
Wenn Sie also die Begeisterung der TDD-Gläubigen ignorieren, können Sie Ihre Arbeit doppelt so schnell erledigen, weil Sie sie nicht benötigen Warten Sie 10 Minuten (oder länger! Ich habe eine Testsuite gesehen, die über eine Stunde gedauert hat…), bis die vollständige E2E-Suite ausgeführt wurde, damit der Test fehlschlägt , bevor Sie mit dem Schreiben Ihres Codes beginnen.
Testen Sie außerdem die Benutzeroberfläche überhaupt , wie in Moray Taylors Antwort ausgeführt unter vielen Umständen unpraktisch. Es gibt einige E2E-Teststufen, die auf die Benutzeroberfläche angewendet werden können, aber zum größten Teil scheint sich die Kapitalrendite für den allgemeinen Fall selten zu lohnen.
Das heißt, ich habe an einer Grafikbibliothek gearbeitet, die einmal von über hundert verschiedenen Videospielen verwendet wurde, und einen E2E-Test geschrieben Suite, um zu bestätigen, dass eine Änderung der internen Logik der Bibliothek kein obskures Spiel zerstören würde, das ich noch nie gesehen hatte. Bibliotheken verdienen immer gründlichere Tests. Für die Benutzeroberfläche einer einzelnen Anwendung sind E2E-Tests meiner Erfahrung nach jedoch fast nie sinnvoll.