Unit-test-helper-Methoden?

Ich habe Klassen, die zuvor massiven Methoden, damit ich unterteilt die Arbeit dieser Methode in 'Helfer' - Methoden.

Diese helper-Methoden deklariert private durchzusetzen Kapselung - möchte ich aber unit-Tests der großen öffentlichen Methoden. Ist es gut, zu unit-test-helper-Methoden, auch wenn einer von Ihnen nicht die öffentliche Methode, die fordert es auch nicht, und auf diese Weise können wir erkennen, warum es fehlgeschlagen ist?

Auch, um zu testen, diese mit einem mock-Objekt, die ich brauchen würde, um zu ändern Ihre Sichtbarkeit von private nach protected, ist diese wünschenswert?

InformationsquelleAutor Aly | 2009-12-07

  1. 12

    Eine Möglichkeit ist das weglassen private und setzen Sie die tests in der Packung. Dann können die Prüfungen Aufruf der internen Methoden, aber niemand sonst (= auch außerhalb des Pakets) kann.

    Auch, fehlerhaften internen Methoden sollten Fehlermeldungen erzeugen, die es leicht machen, das Problem zu beheben. Wenn Sie den code in die Produktion, werden Sie sehen, weniger als die tests, und Sie werden unter einer Menge Druck, um die Probleme zu beheben schnell. So eine minute, die Sie hier verbringen werden, sparen Sie eine Stunde später mit Ihrem Chef sitzen in Ihrem Hals.

    Statt makeing Sie package private, ich es vorziehen, die helper-Methoden geschützt, und testen Sie Sie aus einer anonymen Unterklasse in der JUnit-test.
    Das ist eine fantastische Lösung, ich habe nie gedacht von vor. Es sollte seine eigene Antwort, damit kann ich upvote! 🙂

    InformationsquelleAutor Aaron Digulla

  2. 14

    Diese riecht wie haben Sie den falschen problem. Was du beschrieben hast ist ähnlich wie das erstellen einer sub-"unit-test", die führt mich zu glauben, dass Ihre unit-tests sind wirklich testen eine Einheit, nachdem alle.

    Das ist keine Kritik an dem, was Sie versuchen zu tun: von "wo wir heute sind" zu "woanders ist messbar besser" ist ein gewinnzug. Jedoch, es ist ein Vorschlag, der Sie Schritt ein wenig zurück, um zu bewerten, wo Sie sind - zu verstehen, wie Ihre aktuelle situation unterscheidet sich von einigen platonischen ideal, könnte helfen, neue Möglichkeiten zeigen.

    Gibt es viele Vorschläge, die hier über scoping-Ihre Helfer-Methoden. Eine weitere Möglichkeit wäre die überprüfung der Implementierung, um festzustellen, ob es Hilfsklassen, die lauernd in Ihrer aktuellen Umsetzung. Erstellen Sie eine neue Klasse und eine Reihe von tests an übung ist es immer akzeptabel.

    Beachten Sie, dass dieser Ansatz isoliert Sie von der Umgestaltung: Sie können ändern Sie die Implementierung ohne änderung der test-suite (weil die unit-tests für das helper-Objekt weiter, passieren auch, wenn der Helfer-Objekt ist nicht mehr Teil Ihrer Produktion-Umsetzung), und Sie erhalten eine saubere Verpackung der Implementierung und der tests für die es (Anwendungsfall: Sie entscheiden, bozo-sort ist die falsche Umsetzung, und sollten nicht mehr verwendet werden. Wenn die bozo-sort Durchführung isoliert ist, dann kann man einfach entfernen und die tests. Aber wenn die tests der bozo-sort-Implementierung sind die Wirren, die mit allen anderen tests, es gibt noch mehr denken).

    Es kann auch helfen, zu überprüfen, warum haben Sie unit tests für Ihren code. Wenn einer der Gründe ist, "um refactoring-safe", dann werden Sie nicht wollen, zu schreiben tests, die sperren Sie in eine Implementierung.

    InformationsquelleAutor VoiceOfUnreason

  3. 8

    Wenn deine Klasse wirklich so groß ist, dann klingt es, wie Sie sein sollte ausbrechen Helfer Objekte, nicht nur Helfer Methoden (obwohl das extrahieren von Methoden ist oft ein Schritt auf dem Weg). Sobald Sie dies getan haben, können Sie Ihre alte Klasse wird einfacher und einfacher zu testen (vielleicht mit mocks, vielleicht auch nicht), und Sie können testen Sie die Methoden auf die neuen unterstützenden Klassen direkt.

    Meine Präferenz ist es, zu testen, durch die öffentliche API eines Objekts. Wenn es zu hart ist, dann ist es ein Hinweis, dass das Objekt sollte aufgebrochen werden.

    "Wenn es zu hart ist, dann ist es ein Hinweis, dass das Objekt sollte aufgebrochen werden." Nehmen Sie Ihre upvote.

    InformationsquelleAutor Steve Freeman

  4. 3

    Wenn Sie testen möchten Helfer Methoden, die Sie ändern können Sie von der privaten, aber Sie sollten erwägen, diese.

    Sollten Sie nicht unit test private details Ihrer Implementierung vor allem, weil es ändern könnte durch Umgestaltung und "break" in Ihrem test.

    InformationsquelleAutor Dror Helper

  5. 3

    Ich bin ziemlich schockiert über einige Antworten hier.

    Im wesentlichen einige Leute sagen "Don' T test der privaten code, denn das verstößt gegen die TDD-Paradigma"

    Test der verdammte code. Was Sie tun müssen, um sicherzustellen, dass es funktioniert genau wie es sollte.

    Persönlich, ich würde die Methoden protected oder default, schreiben die tests, die tests auszuführen und bei Erfolg wieder zurück zu den privaten. An diesem Punkt möchte ich kommentieren Sie die entsprechenden tests, und lassen Sie eine Anweisung block über Ihnen:

    /** Tut mir Leid, aber ich erbte ein Durcheinander...
    * wenn Sie brauchen, um zu testen, diese Methoden setzen Sie in Quell-und un-Kommentar die folgenden * Linien
    */

    Aber absolut nie lassen Sie rigide festhalten an einer Entwicklungsmethodik im Wege der Verbesserung der code.

    Ihr Vorschlag ist im Grunde nur, wie dogmatisch - MÜSSEN Sie testen jede Methode einzeln, da es sonst gegen die TDD-Paradigma. Unsinn. Eine helper-Methode kann nur ein gemeinsames Stück code) und der code-coverage-tools können Sie überprüfen, dass die unit-tests für die öffentlichen Methoden fallen alle, wenn es sein muss.
    Amen @M1EK, ich hatte gerade post eine Antwort, da niemand sonst hatte einmal erwähnt, code-coverage!
    Original-Poster den Wunsch geäußert, testen Sie diese Methoden einzeln. "...testen Sie die helper-Methoden, auch wenn einer von Ihnen nicht die öffentliche Methode, die fordert es auch nicht - aber auf diese Weise können wir erkennen, warum es fehlgeschlagen ist."
    Ich denke wir reden über zwei verschiedene Dinge hier. In meiner Welt, die solche tests laufen automatisch die ganze Zeit. Es gibt keine Weise, die ich Leben könnte, bei der änderung von code basierend auf Anweisungen. Ihre Welt ist natürlich anders.

    InformationsquelleAutor Chris Cudmore

  6. 1

    Dies ist einer der Fälle, wo ich sagen würde voran gehen und die Regeln brechen.

    Wenn Sie mit dem Entwurf waren die Klasse von Grund auf, Sie definitiv nicht wollen, helper-Methoden, die in der Einheit getestet auf Ihre eigene, aber... da Sie die Umgestaltung einer vorhandenen Klasse, es ist akzeptabel, die Regeln beugen, um sicherzustellen, dass Sie nicht etwas zu brechen.

    Machen Ihnen geschützt wird, können Sie testen, wie die Helfer selbst, um sicherzustellen, dass Sie immer noch das Verhalten, das Sie erwarten, wie Sie ziehen Sie die Logik von den großen Haarballen-Methode, sowie ermöglichen Sie die stub-und return-fixed-Antworten, so dass Sie sicherstellen können, dass die große Methode, die Sie refactoring verhält sich wie erwartet für bestimmte Ergebnisse von helper-Methoden.

    Aber Sie sind noch nicht fertig an diesem Punkt. Die Spaltung der Methode up nicht wirklich an die Wurzel des Problems. Jetzt haben Sie die Methode aufgebrochen und eine Reihe von (etwas unorthodoxen) tests, die Ihnen zeigen genau, was die Logik macht, Sie sind in einer guten position, um erneut zu prüfen, die ganze Klasse und versuchen Sie herauszufinden, warum die Methode war so groß in den ersten Platz. Wahrscheinlich Ihre ganze Klasse muss auch gebrochen werden in kleinere Einheiten mit diskreten Aufgaben, die dann einfacher zu testen, ohne biegen alle Regeln.

    InformationsquelleAutor Lorin

  7. 0

    Haben Sie grundsätzlich 2 Möglichkeiten:

    1. Erhöhen, den Umfang der helper-Methoden von privat zu Standard. Sie können dann testen Sie diese Methoden (vorausgesetzt, die test-Klassen im selben Paket wie die zu testende Person). Dies verbessert die Testbarkeit der Klasse, aber Sie opfern einen Teil der Kapselung

    2. Lassen alles wie es ist. Dies wird verhindern, dass Sie vom schreiben sehr feinkörnige tests, aber nicht erforderlich, dass Sie Opfer jede Kapselung.

    Persönlich, die ich wählen würde, (2), denn Sie sollten nicht wirklich brauchen, um zu testen privater Methoden. Die Klasse soll getestet werden, durch die öffentliche Schnittstelle (die wiederum rufen die privaten Methoden. Testen von privaten Methoden führen kann spröde tests, d.h. tests, die fehlschlagen, wenn nur der interne Verhalten einer Klasse ändert.

    Gibt es eine Dritte Möglichkeit (die ich nur ungern erwähnen): Verwendung von reflektion (oder einige andere voodoo) zum aufrufen von privaten Methoden in der Testklasse. Dies hat die Nachteile von (1) und auch die Nachteile immanent, reflektierende code (z.B. umgeht die überprüfung von Typ und ist schwer zu Lesen)

    könnte auch eine Unterklasse definiert, die in dem Testfall ruft die protected-Methode, also test-Klassen nicht brauchen, um in der gleichen pacakge als Umsetzung

    InformationsquelleAutor Dónal

  8. 0

    Als Don und Dror sagen, was die Methoden, die öffentlichkeit, so können Sie erstellen unit-tests für Sie bricht die Kapselung. Dann binden Sie sich eine bestimmte Umsetzung. Durch öffentlich zu machen, Sie erklären der Welt, dass diese Methoden sind Teil der veröffentlichten Schnittstelle und daher Ihre Spezifikationen sind gesperrt.

    Persönlich, ich ' D gehen für eine pragmatische Lösung: Halten Sie privat und nicht mit dem schreiben von unit-tests. Wenn Sie an einen Fall, wo eine öffentliche Methode schlägt fehl, und Sie nicht herausfinden können warum, aber Sie denken, es könnte ein problem in einem Ihrer privaten Methoden, die dann vorübergehend machen Sie der öffentlichkeit, schreiben die unit-test -, debug -, und wenn Sie fertig sind, machen Sie privat wieder und kommentieren Sie das Gerät testen.

    InformationsquelleAutor Jay

  9. 0

    Du unit-test-diese-helper-Methoden, die durch das schreiben von unit tests, bei denen diese Teile des Codes.

    Sie definiert ein öffentliches API in dieser Klasse für einen Grund, richtig? Testen Sie, dass. Wenn es funktioniert, ist das Klasse funktioniert.

    Verwenden Sie die code-coverage-tools zu helfen, Sie wissen, ob ein ausreichender Teil der Klasse wird getestet, und wenn es das nicht mehr schreiben unit-tests zur Ausübung der öffentlichen API, und schlagen Sie die Ecken, die nicht erfasst werden.

    InformationsquelleAutor Nick Veys

Schreibe einen Kommentar