2016-05-06 4 views
1

Ich habe Spock Tests gesehen, wo Mocks & im Block given (wo es am meisten Sinn für mich konfiguriert) konfiguriert ist, sowie Fälle, wo der einzige Weg zu bekommen Der Test, um zu bestehen, verlangte von mir, die Mocks innerhalb des then Blocks zu verdrahten/zu konfigurieren, was für mich einfach albern ist. Ein Beispiel für Letzteres ist eine Frage that I asked some time ago. SoSpock Block Mocks und wo sie zu verdrahten

Ich frage: Was bestimmt, wo tatsächlich Draht/config einen Mock, entweder in given oder in then? Ich hoffe wirklich, die Antwort ist nicht nur "weiter damit spielen, bis es funktioniert", denn das ist zu unbestimmt für mein winziges Robotergehirn.

+0

können Sie den Titel dieser Frage so ändern, dass er sich mehr reimt? – Kritner

+0

das war beabsichtigt :-) – smeeb

Antwort

2

Mocks und Stubs sollten im setup/given Block oder sogar in der setup() Methode instanziiert werden, wenn Sie sie in mehreren Tests verwenden und den Boilerplate reduzieren möchten.

Mocks und Stubs Verhalten sollte meiner Meinung nach im engsten Bereich, der Sinn macht, definiert werden. then macht normalerweise den meisten Sinn, aber das Definieren von allgemeinem Verhalten, das Sie nicht wirklich sorgfältig prüfen, könnte in den setup/given Block oder sogar in die setup() Methode gesetzt werden.

+0

Dank @Jon Peterson (+1) - Ich (respektvoll) stimme nicht überein über 'dann' macht den meisten Sinn, aber das ist ein subjektives Argument, ich bin nicht daran interessiert, jetzt zu machen! ** Allerdings **, wie der Link oben zeigt, gibt es sicherlich Anwendungsfälle für die Verkabelung/Konfiguration von Mocks innerhalb des 'gegebenen '* funktioniert einfach nicht *. Und meine Frage ist ** was treibt das an? ** Was bedeutet, in welchen Szenarien funktioniert die Verkabelung/Konfiguration von Mocks in 'gegeben' und wann muss das in 'dann' gemacht werden? Danke noch einmal! – smeeb

+1

In der anderen Frage glaube ich, dass, wenn Sie die 'fizz1.getProperty ('name')' anstelle von 'fizz1.name' im' gegebenen' Block verwendet hätten, hätte es auch funktioniert. –

+1

Der Grund für Ihre Verwirrung bezüglich der "kontraintuitiven" Natur von Spock liegt wahrscheinlich an Ihren Erfahrungen mit anderen Java-Spionage-Frameworks. Spock macht etwas unter der Haube, um die Erwartungen im 'then' Block vor dem' when' Block zu nennen. Fügen Sie einen Debugger hinzu und Sie sehen die Reihenfolge, in der die Dinge aufgerufen werden. Wenn ich Nicht-Spock-Mocking verwende (wie Camel MockEndpoints), verwende ich normalerweise 'expecte' Blöcke anstelle von' when'/'then', so dass ich die Erwartungen manuell anordnen kann, wie ich sie haben möchte. –