Björn Kautler

Well first and last are no valid reasons imho as mentioned earlier. Third is not really an argument as you either have a tool where you can select it, or...

Oh, hm. I was aware of all but the part about data provider methods not being interceptable. That's unfortunate of course. Maybe this would be a chance to add this...

If you are using 1.3, I don't think so. If you using 2.0 milestone build, many things changed and you could get it from the parent. But maybe it would...

Extensions are availble in 1.3 and 2.0 the same, that's why I said it is more portable to use them. But if you mix JUnit and Spock tests and get...

Is this meant as bug report or feature request?

Well, it is the expected and documented behavior. http://spockframework.org/spock/docs/1.3/all_in_one.html#_implicit_and_explicit_conditions clearly says > Except for calls to void methods and expressions classified as interactions, all top-level expressions in these blocks are...

Well, do you have a good set of rules for verification? Just using any expression is bad too. Imagine for example `expect: result.any { it != null }`.

No it is not. :-) `org.junit.AssumptionViolatedException` is a JUnit 4 class. Spock 2+ is based on JUnit 5. Either throw `org.opentest4j.TestAbortedException` instead, or add the `spock-junit4` artifact to your runtime...

> Adding the spock-junit4 artifact fixed my problem Well, it didn't fix it, it work-arounded it. You should better fix it by using the correct exception. The spock-junit4 artifact is...

It's actually even worse and more inconsistent. The Windows start scripts run it within the start script containing directory. The Linux start script runs it within the `BIN_DIR`. O_O