Mockito vorzuziehen über EasyMock?

Kürzlich machte ich den Schalter auf Mockito-framework und bin sehr zufrieden damit (siehe auch blog-post). Der Wechsel von EasyMock für Mockito war sehr einfach und ich es geschafft, die Prüfungen nach unten kompatibel (d.h. test-Fällen Verhalten sich die gleichen).

Sehen Sie die wahren Gründe oder shootout-Kriterien zu bevorzugen, EasyMock über Mockito? So weit die Codebasis mit dem ich arbeitete, kann ich nicht, bin aber interessiert an eurer Meinung.

InformationsquelleAutor manuel aldana | 2010-06-27
  1. 22

    Mockito wurde entwickelt, um eine BDD-style-unit-Tests, das heißt:

    • Gegeben (der Kontext, in dem Sie Ihre unit-test läuft)
    • Wenn (die Ereignisse produzieren, die das Verhalten, die Sie interessiert)
    • Dann (das Ergebnis, die Sie suchen).

    im Gegensatz zu

    • Gegeben
    • Erwarten (hier ist, wo die Prüfung gemacht wird)
    • Wenn
    • Dann (zurück gehen und sehen, was Sie schrieb, im Rechnen, weil es keine tatsächliche info hier).

    IMHO es produziert mehr lesbar tests, und ermöglicht es Ihnen, die Dinge zu trennen, wie der Kontext, in dem Sie ausführen (einstellen der Verspottet) und überprüfung des Verhaltens, das Sie interessiert. Vorherige mocking frameworks benötigt Sie, um die Erwartungen für jede Interaktion, unabhängig davon, ob es relevant war, um den Aspekt des Verhaltens, die Sie bei uns waren im test oder nicht.

    • das stimmt nicht, Sie nicht haben, um "set up Erwartungen für jede Interaktion'. Mit Easymock können Sie einfach setup ein NiceMock (createNiceMock()). Trotzdem denke ich, dass der Test-Objekt-Interaktion ist eine gute Idee (und das sollte Standard/common Verhalten).. ich verwende selten niceMocks
    • Mockito war ursprünglich ein fork von EasyMock, bevor NiceMock existierte. Im BDD, Sie sind keine tests - nur Beschreibungen von Verhaltensweisen, mit einigen Beispielen, wie man eine Klasse verwenden. Die Idee von BDD ist es einfach und sicher zu ändern, anstatt pinning Sie den code unten, damit es nicht bricht. Tests sind ein nettes Nebenprodukt. In dieser Welt, testen jede Interaktion macht nicht so viel Sinn, wie zu produzieren lesbar, einfach-zu-ändern-Beispiele.
    • Ich will testen, mein code.. dann wenn es gut lesbar und einfach zu ändern, ist es eine andere Geschichte.. ich glaube nicht, dass TDD Experten würden bestätigen, dass "die Interaktion macht nicht viel Sinn'. Sie produzieren immer etwas aus der Interaktion von Komponenten,... ich lieber etwas, das weniger lesbar, aber testen Sie die richtigen Interaktionen .. IMHO Interaktion (als lesbar / easy-to-change code) ist ein wichtiges Thema in der Prüfung und sollte nicht vermieden werden, so einfach
    • Ich glaube nicht, dass TDD Fachkräfte BDD-Experten. Ich habe auch nie gesagt "die Interaktion macht nicht viel Sinn" - bitte Lesen Sie den Wortlaut, die ich tatsächlich verwendet und den Kontext Bedenken.
    • Ich wollte nur darauf hinweisen, dass Mockito ist nicht der einzige Rahmen, der erschaffen kann, Stubs. Ich denke nur, Interaktionen sind MEHR/ALS relevant als lesbaren code. Dieser Kerl hier martinfowler.com/articles/mocksArentStubs.html , und andere hier, amazon.co.uk/Wachsen-objektorientierte-Software-Guided-Unterschrift/... verwenden, Interaktion sowie zum Antrieb Ihrer Entwicklung.
    • Wenn ich bereits geschrieben hatte, die BDD-Buch mit Dan nach Norden, würden Sie mir Vertrauen mehr? 😉 Hier ist ein BDD-Beispiel. Wir haben einen controller, der überprüft, vor der übermittlung an das repository. Ein Beispiel umfasst die Validierung. Die anderen Deckel spart durch das repository. Wir haben zwei Beispiele, die zeigen, diese beiden Aspekte des Verhaltens. Mit Mockito, wir nicht brauchen, um zu überprüfen, Validierung für das Beispiel, das zeigte, daß wir gerettet, das Element, das half, devs, die neu waren, um den code zu verstehen, was es Tat. Macht das Sinn? Wir nur tests schreiben, um die Dinge sicher zu ändern - sonst könnten wir ja testen manuell.
    • Ich mag die definition von xunitpatterns.com/Test%20Double.html, was macht die test-Aspekt sehr klar. Ich benutze Mockito Test-Stubs, die Test-Mocks-und Test-Spion. Ich gehe der Mitte/auf pragmatische Art und Weise das schreiben von tests, sollen Sie einfach schreiben, Sie sollte aber auch-test "etwas" (um nicht "falsch-negative" Testergebnisse). Sicher, easymock (wenn Sie nicht mit nett-mocks) ist mehr strenge und theoretisch mehr richtig, aber es erzeugt eine Menge Verwirrung-test-Fällen. meiner Ansicht innen Testfälle überprüfen Schritt sollte das Letzte und nicht vermischt werden mit dem setup (wie 'erwartet' in easymock).
    • Ich mag die definition, aber (weil BDD basiert teilweise auf NLP -) ich nenne es lieber ein Mock: Eine imitation, die meist mit der Konnotation, dass es eine von geringerer Qualität (wiktionary.org). Ich nenne Sie das, ohne sich sorgen zu viel über Sie, ob Sie die Einrichtung Kontext, überprüfung der Ergebnisse, hand-codiert oder mit einem Rahmen, weil es ein geltendes Englisches Wort, und ich mag Englisch. Business-Leute sind gelegentlich erschrocken durch das Wort "test" oder die Idee, dass Sie möglicherweise haben, zur Verfügung zu stellen. Verstehen Sie "Beispiel" oder "Szenario", aber, und haben kein problem mit Ihnen.
    • So ... das ist der Antwort auf stackoverflow.com/questions/6177296/... einfach "es kann nicht getan werden, EasyMock" ?

    InformationsquelleAutor Lunivore
  2. 7

    Ich bin mehr vertraut mit EasyMock als Mockito, also ich musste ein wenig Graben. Mockito ist ein Seite, dass nicht ein expliziter Vergleich von Mockito Sicht.

    Wie ich es sehe, sind die Vorteile von Mockito sind:

    • Explizite Trennung von stub und überprüfung
    • Matcher basieren auf Hamcrest (auch mit Unterstützung von JUnit), statt eine benutzerdefinierte API
    • Erstellte mocks sind immer 'schön';, die ist, Methode Aufrufe, die unmocked Rückkehr saubere Daten (wie eine leere Liste), anstelle der versagenden

    EasyMock hat eine sehr ähnliche Funktion eingestellt. Der Kern Unterscheidungsmerkmale für Mockito basieren auf diesen Gebieten EasyMock, dass die Mockito-team gedacht waren Einschränkungen oder sub-optimale Praktiken.

    Aus funktionaler Sicht, keines der beiden Produkte ist in der Lage, zu verspotten statische Methoden (ich musste das tun, für die Prüfung, ohne einen MBeanServer), aber in diesem Fall können Sie mit PowerMock entweder Rahmen.

    Ich würde sagen, gehen mit, welcher Stil passt zu Ihrem Test-Anforderungen.

    Hoffe, das hilft!

    InformationsquelleAutor mlschechter
  3. 6

    Mockito kann jetzt besser als es war, als ich das Letzte mal versucht, aber es mich verloren, wenn es verändert seine API nicht kompatibel mit früheren Versionen. Upgrade auf die neueste version nötig gewesen wäre, mich zu ändern viele meiner vorhandenen unit-tests, die ich gefunden habe, nicht akzeptabel. Ich beschlossen, es war zu unreif und instabil für meine Bedürfnisse.

    Das bedeutet nicht, dass es etwas falsch mit ihm, obwohl. Die version, die ich war mit funktioniert immer noch gut, obwohl, ich habe da wieder eingeschaltet, um EasyMock.

    • Ich kann dieses Bild war schmerzhaft. In meinem Fall war ich bereits mit der version 1.8.3. Blick auf die release-notes die API scheint sich stabilisiert zu haben.
    InformationsquelleAutor Brandon Yarbrough
  4. 1

    Hier ist ein journalistischer Blick.

    Fall für Mockito:
    http://code.google.com/p/mockito/wiki/MockitoVSEasyMock

    Fall für EasyMock:
    http://blog.octo.com/en/easymock-facts-fallacies/

    InformationsquelleAutor Barett
Schreibe einen Kommentar