Same design strategy of Solution #1 Take #1 but with the brand new Java ...

[matteobaglini]

...8's lambda. Without the AnonimousClass verbosity the code is a lot more readable.

[giancosta86]

Very brilliant and elegant idea! ^_^!
Of course, possible only if we can freely change the Service without breaking existing dependencies X___X'.
I'm just performing a small change to reduce the visibility of the variable modified by the lambdas! ^^

[matteobaglini]

Through refactoring, tiny steps and parallel design we can put this design in production without breaking existing dependencies. Given that, the tests use mock objects, they are heavily coupled to the Service interface so, in order to introduce my design, without getting red bar, I have already had to use the parallel design technique.

[arialdomartini]

@matteobaglini Great! Apparently, I belong to the London TDD School and you are likely to sympathize with the Chigago (or Detroit?) one. It's pretty funny that such simple code quizzes could hide so many interesting sides, isn't it?

I would love the same tests converted to a different style, more state based and less coupled to the interface.
Would you like to try?

[matteobaglini]

@arialdomartini sure, but in this simple case the switch of testing style will not produce a really different test. This because despite the use of a moking framework the injected service test duble is a stub (not a mock). In the Chigago style we can use read object (preferred choice) or stubbed dependencies (regardless of whether they are done handmade or with a framework).

Sum up, the final result would be the same. :-)