Why I prefer Spock over JUnit by Bouke Nijhuis

[@Greatfulone]

I agree. I really like Spock. I find Junit's ArgumentProviders especially when you want to create your own POJO kind ofcomplex.

[@MrEmanon89]

I dont know why people debate that JUnit is more readable than Spock. Really nice presentation Bouke

[@bnijhuis1]

Thanks for the compliment!

[@cya3mdirl158]

Maybe they'are junit fanboys

[@SwarangaSarma]

I am sure the framework is nice but his arguments are not convincing. And the examples are too simple IMO. His primary point seems to be conciseness which I won’t contest. But his argument about operator being more readable than method is weak. How is when(instance.method()).thenReturn(value) less readable than his operator example? The method version reads more like English and can be understood even if you don’t understand Java. About the example with the data table, that example is nice but how does it work when my values are not simple primitives but complex classes with many constructor arguments. In Junit I can align them in multiple lines and they will look readable; how will the pipe work for such cases?

[@bnijhuis1]

Thanks for watching my session at Devoxx. Thanks a lot for giving feedback! For easy comparison I have put the Junit & Spock way under each other. The first line is the line you provided and the second line is what it would look like in Spock. when(instance.method()).thenReturn(value) instance.method() >> value I prefer the second way, because of the following arguments: - it is shorter - less dots & parenthesis - more spaces (so a clear separation between the method and the return value) So I am able to parse the Spock line much faster than the Junit line. Furthermore you are asking about datatables with more complex variables. I have provided an example here. static String longMethodCall = String.format("%s %s %s %s %s %s %s %s", "", "", "", "", "", "", "", "") void "bigger datatable example"() { expect: a == b where: a | b new String("a") | new String("a") longMethodCall | " " } I am not really happy with the static outside of the test method. Unfortunately I was not able to get it inside the test method. There is another way, which looks more like the JUnit way: spockframework.org/spock/docs/1.1/all_in_one.html#_data_pipes I hope this helps. Thanks again!

[@TanayPrabhuDesai]

@@bnijhuis1 Some points that I'd like to add about readability. Firstly you need to call it instanceMock instead of calling it instance which will tell you what the operator is doing. Secondly, unless you know mockito and mocking, there is very little chance to know what when(instance.method()).thenReturn(value) actually does.

[@SwarangaSarma]

@@TanayPrabhuDesai Sure, I guess readability is subjective. For me though, without knowing Spock, I have no idea what instance.method() >> value is doing. Is it like those operators in C++ to set or read values? Like cin >> or cout

[@electricant55]

@@SwarangaSarma It takes 1 minute to learn what >> in Spock does, compared to how many hours spent over the course of the project on writing extra boilerplate?