Schreiben "unit-testbaren" code?

Welche Art von Praktiken die Sie benutzen, um Ihren code für mehrere unit-Test-freundlich?

InformationsquelleAutor Dana Holt | 2009-06-17
  1. 53

    • TDD -- schreiben die ersten tests, Kräfte
      Sie denken über die Testbarkeit und
      hilft schreiben Sie den code, dass ist eigentlich
      gebraucht, nicht was Sie denken, Sie können
      müssen

    • Umgestaltung der Schnittstellen zu -- macht
      die Verspottung einfacher

    • Öffentlichen virtuelle Methoden, wenn nicht mit
      Schnittstellen-macht die Verspottung einfacher

    • Dependency injection -- macht mocking
      einfacher

    • Kleinere, mehr gezielte Methoden --
      tests sind mehr konzentriert, leichter
      schreiben

    • Vermeidung von statischen Klassen

    • Singletons vermeiden, außer dort, wo
      notwendig

    • Vermeiden versiegelte Klassen

    • ja, dass etwa abdeckt
    • "Singletons vermeiden, außer wenn nötig" -- nicht entsprochen Haben einen Fall, wo es notwendig war, in meinen 10 Jahren auf die Programmierung.
    InformationsquelleAutor tvanfosson
  2. 12

    Dependency injection scheint zu helfen.

    • Yep, das ist meine Lieblings-Empfehlung zu -- auf diese Weise werden die unit-tests können leicht ersetzen die mock-Objekte für was auch immer Abhängigkeiten, Sie sind gespritzt.
    • Ich denke, dependency injection kritisch ist (Handbuch ist in Ordnung, Sie brauchen nicht zu verwenden, ein DI-framework). Ohne es die meisten tests sind gezwungen zu werden Integrationstests anstelle von unit-tests.
    • ja, ich habe festgestellt, dass 'manuelle ist in Ordnung" für meine Anwendungen, sowie
    InformationsquelleAutor dss539
  3. 9

    Schreiben die ersten tests - so die tests fahren Sie mit Ihrem design.

    InformationsquelleAutor Shane Fulmer
  4. 6
    1. Verwenden TDD
    2. Beim schreiben Sie den code nutzen, dependency injection, wo immer möglich,
    3. Programm-Schnittstellen, keine konkreten Klassen, so können Sie Ersatz mock-Implementierungen.
    • aus Neugier, was wäre, wenn Sie die Verwendung von TDD, aber nicht verwendet dependency injection überall, und verwendet konkrete Klassen in vielen Orten, und nicht verhöhnt die ganze Zeit; habe alle diese schlechten Dinge, aber fertig mit 90% oder mehr code-coverage. Möchten Sie, dass Sie ein schlechter Mensch, oder würde es bedeuten, dass nicht all das andere Zeug war wirklich notwendig für die Qualität?
    • Interessante Frage. IME-unit-Test ohne diese Dinge sehr, sehr schwierig wird, und ich glaube, ich würde mich Wundern, wenn die 90-Prozent-Deckung wurde die 90% - war in der Lage zu testen, anstatt den 90%, dass die erforderlichen Tests 😉
    • Ich nicht ziemlich viel, was ich mache, und ich würde sagen, ich bekomme immer noch die meisten Vorteile in Bezug auf Qualität - das problem ist, dass das schreiben des tests ist härter, und pflegen ist mehr Arbeit.
    • Ich Schreibe fehlgeschlagene tests zuerst. Es gibt keinen code, der geschrieben wird, es sei denn, es wurde geschrieben, um fehlgeschlagene tests übergeben. Daher die 90% Abdeckung ist, per definition, die 90%, die benötigte Test - er würde nicht existiert haben, außer für die Prüfungen.
    • es ist nichts falsch mit der Durchführung der DI, verspottet, etc. als eine praktische Sache, um die tests und halten Sie Sie pflegen. Ich Folge den rot-grün-refactor-Regel, so bin ich ständig refactoring beide tests und code; wenn DI verbessern wird einige tests, dann DI passiert.
    • wie groß ist eine "Einheit" in Ihr unit tests? 1 Methode? 1 Methode, die Anrufe 12 andere Methoden? Haben Sie eine single-unit-test, das deckt mehr als 100 Zeilen code? DI es erlaubt, sehr kleine Einheiten werden getestet, und DI ist ziemlich leicht zu "bolt-on" legacy-code. Wenn Sie in der Lage, leicht test kleine Einheiten ohne DI, dann bewundere ich Ihre design-Fähigkeiten und lernen konnte, ein paar Dinge von Ihnen. Wenn, jedoch, Sie sind Tests, riesige Brocken von code mit jedem test, dann Schande über Sie. 😛
    • Ich bin ein Alter Hund, und nur gelernt, diesen trick vor fünf Jahren, ich weiß also nicht so (basierend auf tests, die pro-Methode, etc). Wie in Beck, wähle ich ein Stück Funktionalität implementiert werden, und schreibt einen fehlschlagenden test. Wenn es zu viel in einem Zug, werde ich beginnen, das schreiben von tests für kleinere Stücke. Nach der Umgestaltung der erfolgreichen tests, können Sie wind-up kombinieren und zu größeren tests, aber nicht, bis Sie haben, einzeln übergeben.

    InformationsquelleAutor PaulJWilliams
  5. 6

    Sicherstellen, dass alle Ihre Klassen Folgen Sie den Prinzip Der Einzigen Verantwortung. Einzelne Verantwortung bedeutet, dass jede Klasse sollte eine und nur eine Verantwortung. Das macht unit-Tests viel einfacher.

    InformationsquelleAutor Robert Cartaino
  6. 5

    Beim schreiben von tests (wie mit jeder anderen software-task) Don ' T Repeat Yourself (DRY-Prinzip). Wenn Sie test-Daten, die nützlich für mehr als einen test, dann legen Sie es irgendwo, wo beide tests verwenden können. Nicht kopieren Sie den code in beiden tests. Ich weiß, dies scheint offensichtlich, aber ich sehe, es passieren die ganze Zeit.

    • +1 die meisten Entwickler denken, "Oh, es ist nur test-code, who cares, wenn it' s Scheiße?", das ist traurig, weil der code, den Sie normalerweise schreiben ist schon beschissen genug!
    InformationsquelleAutor ssteidl
  7. 4

    Der einfachste Weg ist nicht überprüfen Sie in Ihrem code, es sei denn, Sie prüfen in tests mit ihm.

    Ich bin kein großer fan von schreiben des ersten tests. Aber eine Sache, die ich glaube sehr stark ist, der code muss geprüft werden, in mit tests. Nicht einmal eine Stunde oder so vor, togther. Ich denke, die Reihenfolge, in der Sie geschrieben werden, ist weniger wichtig, so lange wie Sie kommen zusammen.

    • der Grund zum schreiben des tests vor dem code ist, dass, wenn Sie check-in-tests, werden Sie wissen, dass Sie den code testen Sie Check-in. Andernfalls bist du nur abhängig von genialen Entwicklern, um sicherzustellen, dass die tests wirklich etwas testen, was zählt.
    • Sie sind abhängig von Brillanten Entwickler auf jeden Fall. Es ist keine perfekte Prozess, der wiederum einen vollständigen idiot, der sich in ein Genie. Dummheit findet IMMER einen Weg, um zu gedeihen innerhalb eines Prozesses.
    • Ich bin nicht einverstanden. Das schreiben des ersten tests können Sie nur garantieren, welche Methoden aufgerufen werden, nicht, welcher code ausgeführt wird. Das sind zwei sehr verschiedene Fragen, und die letzteren, die viel mehr wichtig. Meine Gruppe hat sich nicht auf die genialen Entwickler, um sicherzustellen, code richtig geprüft wird, verlassen wir uns auf Profiler zu machen, dass die Anruf.
    • Nein, die tests sind gedacht, um nicht zuerst. Der code ist nur geschrieben, um die tests übergeben. So die tests beweisen, dass Sie etwas testen, was zählt. @dss539: ich meinte, dass wenn Sie nicht schreiben die ersten tests, Sie sind darauf angewiesen, Ihre genialen Entwickler code-reviews oder der Suche auf Ihrer eigenen code, um sicherzustellen, dass die Prüfungen, die Sie check-in tatsächlich test genau das richtige. Ohne den fehlerhaften test-first, code nicht beweisen, so haben Sie zu verlassen auf den Menschen.
    • Sie haben einen starken Punkt-zu-test-erste geben gute Abdeckung, aber eine dumme/böse-Entwickler kann immer noch schreiben schlechte tests. Andernfalls zuerst, dann vorbei an einem test ist nicht unbedingt ein guter Indikator, dass der test funktioniert in mehr als einem Fall. Sie kann aber helfen, intelligente Entwickler denken über den besten Weg, um zu testen. Also ich sage nicht, Sie haben eine ganz schlechte Idee. Eher, ich denke nur, es ist nicht ein Allheilmittel.
    • dass es beweist, dass das getestet, dass bestimmte Methoden aufgerufen werden, und es sind eine Reihe von beobachtbaren Nebenwirkungen. Es sagt nichts darüber aus, was der code war eigentlich getestet obwohl. Es kann sein, ein Meer von code zwischen einen Methodenaufruf und eine Nebenwirkung. Nur ein profiler kann garantieren, was code wurde tatsächlich getestet. In dieser Hinsicht TDD ist nicht besser als die überprüfung in tests an der gleichen Zeit.
    • code coverage ist eine eigenständige und interessante Sache. Der Zweck eines test-nicht um zu testen, code: es ist zu testen, dass der code, genannt, die durch den test verursacht, die richtigen Dinge zu passieren. Ich bin nicht unbedingt die Pflege code aufgerufen wird, zu erreichen, der richtige; denn ich Schreibe minimal-code, um diese tests zu bestehen, am Anfang, es gibt wenig "extra", das wäre nicht erforderlich, für einen test zu bestehen.
    • Außerdem ist es offensichtlich notwendig, zu überprüfen, test-Listen und tests, wie einer von Bewertungen-code: in größerem oder geringerem Umfang, je nach Zeitpläne, Personalbedarf, Fachwissen, etc. Die Idee wäre, fangen die bösen Entwickler, die lieber früher als später.
    • Ich kann nicht erkennen, wie TDD gewährleistet dies besser als das schreiben der tests nach dem code, aber bei der Prüfung zur gleichen Zeit. Du bist immer noch abhängig von der Entwickler, das richtige zu tun.
    • mit einer Entwickler-ich hatte kein Vertrauen zu Professionell sein, ich würde überprüfen Sie die Liste der vorgeschlagenen tests und Prüfungen, bevor Sie Sie annehmen. Dies würde zu fangen tests, die testen nicht alles, oder tests, die sich selbst testen, etc. Beachten Sie nicht nur tests schreiben, Sie zunächst tests schreiben, die fehlschlagen. Nur durch die Schaffung von code, um Sie passieren zu tun, die Sie jemals passieren. Der Prozess, wenn Sie befolgt werden, produziert die minimal-code, der die tests besteht, die geschrieben wurden (und das zuerst nicht, aber pass nun, dass die minimale code geschrieben wurde). Vielleicht ist das der Grund für pair programming?
    • zunächst schreiben eine Liste von vorgeschlagenen tests; diese Liste wird sich ändern. Schreiben Sie die erste testen und sehen es nicht. Dann schreiben Sie den minimalen code, um die test-pass. Sie wissen jetzt, dass der test testet den code, den Sie schrieb. Refactor-test-und code -, test erneut ausführen, dann auf zum nächsten test. Es wird auch kein code geschrieben wurden, die nicht nachweislich korrekt ist, indem Sie das Maß der "macht einer fehlerhaften test pass". Es wird mindestens das Maß für die Qualität des tests. Ohne, dass, die Sie benötigen ein anderes Maß dafür, ob die tests egal. Vielleicht ist gerade das Vertrauen in Ihrem team. Vielleicht ist das Gebet.
    • Sie widersprechen Ihren ursprünglichen Punkt. Aus der Sicht der person, die nicht den code schreiben, Sie sind immer noch abhängig von einer "genialen Entwickler" das richtige zu tun. Wie kann ich als code-reviewer weiß, Sie haben es der richtige Weg ist? Ich denke, die Reihenfolge, in der Sie code schreiben, der / die tests weitgehend irrelevant ist, wenn Sie beide aktiviert in zusammen. Code-coverage - + 'sanity checks' während der code-review ist der einzige Weg, um zu bestimmen, wie gut die tests wirklich sind. Selbst dann haben Sie zu setzen, den glauben in der code reviewer.
    • Ich nehme an, ich bin je nach Entwickler, verstehen und befolgen Sie den Prozess richtig. Nicht nehmen Brillanz: mit einem Junior Entwickler, kann er verlangen, pair programming oder Aufsicht, aber nicht Glanz. Ich bin angewiesen auf etwas, um sicherzustellen, das richtige Verfahren weiter verfolgt werden; noch, keine Brillanz. Es ist die Prozedur, die sicherstellt, dass die tests geschrieben wird nur passieren, wenn der code so geschrieben, dass Sie passieren. So, die tests überprüft, die in sinnvolle, nicht das, was ein genialer dev entscheidet, sinnvoll ist. Er werde sein Recht. Junior will nicht.
    • Es ist auch nicht erforderlich, eine brillante dev Blick auf die öffentlichen API-Platz in Ihrer Klasse und Autor-tests entsprechend. Junior dev tun können genauso gut. Ich sehe nicht, wie dieser Prozess ermöglicht eine stärkere Garantien als unit-tests + code-coverage. Ich würde verlassen sich lieber auf harte zahlen.
    • Ich will nicht die tests verfasst, um die öffentliche API. Ich möchte die Implementierung der API erstellt werden, indem fehlerhaften unit-tests übergeben. Dass endgültig bindet die tests, um den code getestet, durch eine praktische Verbindung (wenn der code nicht funktioniert hat, der test würde nicht passieren - wenn der test noch nicht geschrieben, der code würde nicht geschrieben worden sein). Von "Brillanz", meinte ich zu beschreiben, ein Ersatz für die praktische Verbindung. Einige Organisationen beschäftigen devs gut genug, um die gleichen oder bessere Ergebnisse. Andere wollen Sie haben, und wäre besser, verwenden TDD statt.

    InformationsquelleAutor JaredPar
  8. 4

    Kleinen, hoch kohäsive Methoden. Ich Lerne es auf die harte Weise. Stellen Sie sich vor Sie haben eine öffentliche Methode, mit der Authentifizierung. Vielleicht hast du TDD, aber wenn die Methode wird groß, es wird schwer sein, zu Debuggen. Stattdessen, wenn Sie, dass #authenticate-Methode keine Sachen in einem mehr pseudo-codish Art und Weise, fordern andere kleine Methoden (vielleicht geschützt), wenn ein Fehler auftaucht, ist es einfach zu schreiben, neue tests für diese kleinen Methoden und finden Sie die fehlerhafte ein.

    InformationsquelleAutor Maximiliano Guzman
  9. 4

    Ist und etwas, das Sie lernen, das erste, was in OOP, aber so viele scheint zu vergessen: Code Gegen Schnittstellen, Nicht Implementierungen.

    • Ich denke, es hängt davon ab, Wann Sie gelernt. Das ist nirgendwo in der Nähe der oben auf meiner Liste der OO-Praktiken.
    • Es hängt davon ab, was er unter "Schnittstelle". Wenn er meint, "die Verwendung der C# - interface Schlüsselwort eine Menge", dann Nein, das ist nicht so sinnvoll. Wenn er meint, "behandeln Sie andere Objekte als black boxes zu akzeptieren, dass einen vordefinierten Satz von Nachrichten", dann ja, das ist hilfreich
    • Dem würde ich Zustimmen, aber das "interface-vs. implementation" - Dichotomie schlägt ISomethingOrOther.
    InformationsquelleAutor alexn
  10. 4

    Verbringen Sie einige Zeit die Umgestaltung untestable code, damit es getestet werden. Schreiben Sie die tests und 95% Abdeckung. Tun, die mich gelehrt, alles, was ich brauche, um zu wissen, über das schreiben von testbarem code. Ich bin nicht gegen TDD, aber das lernen die Besonderheiten von dem, was macht code testbar oder nicht testbar hilft Sie denken über die Testbarkeit zur design-Zeit.

    InformationsquelleAutor Robert
  11. 4

    Schreiben Sie nicht untestable code

    InformationsquelleAutor cwash
  12. 4

    Ich bin sicher, ich werde nach unten für diese gestimmt, aber ich Stimme der Meinung sowieso 🙂

    Während viele der hier genannten Vorschläge gut gewesen, ich denke, es muss getempert werden, ein bisschen. Das Ziel ist es, mehr zu schreiben, robuste software, die änderbar und wartbar.

    Das Ziel ist nicht, code, unit-testbar. Es gibt eine Menge Mühe in die Herstellung code mehr "getestet", trotz der Tatsache, dass testbaren code ist nicht das Ziel. Es klingt wirklich schön und ich bin sicher, es gibt Menschen die warmen fuzzy, aber die Wahrheit ist, dass all diese Techniken, frameworks, tests, etc, kommen zu einem Preis.

    Kosten Sie Zeit in der Ausbildung, Wartung, Produktivität, Aufwand, etc. Manchmal lohnt es, manchmal nicht, aber Sie sollten nie setzen Sie die Scheuklappen auf und berechnen Sie voran mit Ihren code-mehr "getestet".

    • +1 für den gesunden Menschenverstand-1, weil durch die Natur des seins testbaren code wird mehr änderbar und wartbar
    • +1 für etwas Vernunft! Unit-tests sind toll, aber TDD ist ein großer sap auf, Dinge schnell erledigt, wenn tests werden verwendet, um cover alles. Wenn Sie tests für triviale oder boilerplate-code, wie Getter/setter, ist es wahrscheinlicher, dass Sie fehlgeschlagene tests aufgrund von änderungen in der Benutzeroberfläche eher als die tatsächlichen Fehler. Smart unit-Tests ist gut. Eifrige unit-Tests führt zu brüchigen code und langsame Entwicklung.
    • Wenn Sie schreiben eine Tonne von boilerplate-code, ist es vielleicht Zeit zu finden, eine neue Sprache.
    • +1 für den gesunden Menschenverstand. Verwenden Sie immer Ihr Gehirn. Aber ich glaube nicht, Schreibe unit tests, so dass ich warm fuzzy und schreiben können, komplizierten code zu machen, fühlte ich mich klug, ich Tue es, weil es macht meinen code mehr änderbar und wartbar sein und ich weiß, dass es funktioniert. Wenn ich es nicht machen, damit mein code funktioniert, ich konnte die Dinge viel schneller!
    • Sie sind richtig, ich habe downvote diese. Schreiben von unit-tests beschränkt, die Sie zum schreiben von code in einer objektorientierten Art und Weise, in Einheiten, die deutliche Abhängigkeiten und können isoliert ausgeführt werden. Dies bedeutet, dass Ihr code ist wiederverwendbar, kommuniziert, was Sie tut, richtig, und keine Beschränkungen auf den rest des Systems. Zusätzlich, Sie werden gehen, um den code zu testen, schließlich, es ist verdammt schade, dass Sie es manuell mit der gesamten Anwendung statt ausführen von code, wird es für Sie tun immer und immer wieder. Schreiben untestable code immer macht das Programm schwieriger zu pflegen.
    InformationsquelleAutor Fred
  13. 3

    Ich die Verwendung von Test-Driven Development, Wann immer möglich, so dass ich nicht haben alle code nicht unit-getestet. Es würde nicht existieren, es sei denn, die unit-test gab erste.

    • Was Sie über UI-code? Und DB-access-layer?
    • Absolut für die DB-access-layer. Ich glaube nicht, dass das Konzept von unit-tests gilt auf UI.
    InformationsquelleAutor John Saunders
  14. 3
    1.Using a framework/pattern like MVC to separate your UI from you
business logic will help a lot. 
2. Use dependency injection so you can create mock test objects.
3. Use interfaces.
    • Ich Stimme zu, Trennung von UI-Logik.
    InformationsquelleAutor Jeffrey Hines
  15. 2

    Check-up dieser Vortrag Automatisiertes Testen von Mustern und Riecht.
    Eine der wichtigsten take-aways für mich war um sicherzustellen, dass der UnitTest code ist in hoher Qualität. Wenn der code gut dokumentiert und gut geschrieben ist, wird jeder motiviert zu halten, bis.

    InformationsquelleAutor Nir Ofry
  16. 1

    Keine Statik - können Sie nicht verspotten heraus Statik.

    Auch google hat ein Werkzeug, dass die Messung der Testbarkeit des Codes...

    InformationsquelleAutor Michael Wiles
  17. 1

    Bin ich immer versucht zu finden, ein Prozess, in dem unit-Test-ist weniger eine lästige Pflicht und etwas, das ich eigentlich tun MÖCHTE. Meiner Erfahrung nach, ein ziemlich großer Faktor ist Ihr Werkzeug. Ich habe eine Menge von ActionScript arbeiten und leider sind die Extras sind etwas beschränkt, wie keine IDE-integration und der Mangel an fortgeschrittenen mocking frameworks (aber guten-Dinge-sind-ein-kommen, also keine Beschwerden hier!). Ich habe getan, test driven development, bevor Sie mit mehr Reife testing-frameworks und es war auf jeden Fall ein mehr angenehme Erfahrung, aber fühlte sich immer noch wie etwas von einer Pflichtübung.

    Vor kurzem jedoch begann ich das schreiben von code in einer anderen Art und Weise. Ich verwendet, um zu beginnen mit dem schreiben des Tests, die Beobachtung einen Fehler haben, code zu schreiben, um den test erfolgreich ist, Spülen Sie und wiederholen Sie und alle, die.

    Nun aber beginne ich mit dem schreiben von Schnittstellen, fast egal, was ich tun werde. Zuerst habe ich natürlich versuchen, das problem zu identifizieren und denken Sie an eine Lösung. Dann habe ich mit dem schreiben beginnen die Schnittstellen zu bekommen, eine Art abstrakte Gefühl für den code und die Kommunikation. An diesem Punkt, ich in der Regel bewusst, dass ich noch nicht wirklich herausgefunden, eine richtige Lösung für das problem als Ergebnis von mir nicht vollständig das problem zu verstehen. Also gehe ich zurück, überarbeiten Sie die Lösung und revidiere meine Schnittstellen. Wenn ich das Gefühl, dass die Schnittstellen unbedingt meine Lösung, ich beginne tatsächlich mit dem schreiben der Umsetzung, nicht die tests. Wenn ich etwas umgesetzt (Entwurf implementationd, in der Regel kleine Schritte), ich fange an es zu testen. Ich immer weiter nach hinten zwischen Prüfung und Umsetzung, ein paar Schritte zu einem Zeitpunkt. Da habe ich Schnittstellen für alles, es ist unglaublich einfach zu injizieren verspottet.

    Finde ich arbeiten wie diese, mit Klassen mit sehr wenig wissen über andere Umsetzung und sprechen nur auf die Oberfläche, ist äußerst befreiend. Es befreit mich von Gedanken über die Umsetzung einer anderen Klasse und ich kann den Fokus auf die aktuelle Einheit. Alles was ich wissen muss ist der Vertrag, der die Schnittstelle bereitstellt.

    Aber ja, ich bin immer noch versuchen zu arbeiten, ein Prozess, der funktioniert super-traumhaft-schrecklich-gut, jeder Zeit.

    Oh, ich wollte auch noch hinzufügen, dass ich nicht mit dem schreiben von tests für alles. Vanille-Eigenschaften, die nicht viel tun, aber die get/set-Variablen sind nutzlos zu testen. Sie sind garuanteed durch die Sprache Vertrages zu arbeiten. Wenn Sie nicht ich habe viel schlimmere Probleme als meine Einheiten nicht überprüfbar.

    InformationsquelleAutor Marcus Stade
  18. 1

    Zum vorbereiten der code testbar sein:

    • Dokumentieren Sie Ihre Annahmen und AUSSCHLÜSSE.
    • Vermeiden Sie große komplexe Klassen, die mehr als eine Sache - halten Sie die Prinzip der einzigen Verantwortung im Auge.
    • Wenn möglich, die Verwendung von Schnittstellen zur Entkopplung von Interaktionen und ermöglichen mock-Objekte injiziert werden.
    • Wenn möglich, machen Scham-Methode virtuell zu ermöglichen mock-Objekte imitieren.
    • Wenn möglich, verwenden Komposition anstatt Vererbung in Ihren designs - auch dies fordert (und fördert) die Kapselung von Verhalten in Schnittstellen.
    • Wenn möglich, verwenden Sie dependency injection Bibliotheken (oder DI-Praktiken), um Instanzen mit Ihren externen Abhängigkeiten.

    , Um das beste aus Ihrer unit-tests ist Folgendes zu berücksichtigen:

    • Informieren Sie sich und Ihr team über die Funktionen des unit-Test-framework, Spott Bibliotheken und testing-tools, die Sie verwenden möchten. Zu verstehen, was Sie können und können nicht tun, wird entscheidend sein, wenn Sie tatsächlich beginnen, schreiben Sie Ihre tests.
    • Planen Sie Ihre tests, bevor Sie beginnen, Sie zu schreiben. Identifizieren Sie die edge-cases, constraints, Vorbedingungen, nachbedingungen und Ausnahmen, die Sie einbeziehen möchten, in Ihren tests.
    • Fix broken-tests in der Nähe zu sein, wenn Sie entdecken Sie wie möglich. Tests helfen Ihnen Mängel aufzudecken und potentielle Probleme im code. Wenn Ihre tests sind gebrochen, Sie die Tür öffnen, um das korrigieren mehr Dinge später.
    • Wenn Sie Folgen einem code-review-Prozess in Ihrem team, code-review Sie Ihre unit-tests als gut. Unit-tests sind genauso ein Teil von Ihr system als jeder andere code - reviews helfen, Schwächen zu erkennen in den tests genauso wie für den system-code ein.
    InformationsquelleAutor LBushkin
  19. 0

    Müssen Sie nicht unbedingt "machen Sie Ihren code mehr unit-Test-freundlich".

    Statt, ein mocking-toolkit kann benutzt werden, um die Testbarkeit betrifft Weg.
    Ein solches toolkit ist JMockit.

    InformationsquelleAutor Rogério
Schreibe einen Kommentar