2

A coworker has recently introduced Spock unit testing into our team's project, and I'm having an annoying problem with its Eclipse integration: whenever we create a parametrized test and use the @Unroll annotation on it, the Eclipse JUnit view loses the association with the test class and shows the results under "Unrooted Tests."

For instance, the results for this test class:

package test

import spock.lang.Specification
import spock.lang.Unroll

class TestSpockTest extends Specification {

    def "Not Unrolled Test"() {
        when: "something"
        then: "one equals one"
            1 == 1
    }

    @Unroll
    def "Unrolled Test #param"(Integer param) {
        when: "something"
        then: "a numer equals itself"
            param == param
        where:
            param << [1, 2, 3]
    }
}

Display this way:

Spock tests annotated with @Unroll display under "Unrooted Tests"

How can I get the unrolled test cases (e.g. "Unrolled Test 1") to show up under "test.TestSockTest" like "Not Unrolled Test"? Is there some naming convention for my Spock tests that the Eclipse JUnit plugin will understand?

I'm using:

  • Eclipse Kepler SR1
  • spock-core-0.7-groovy-2.0
  • Jspresso Spock Plugin 2.71
  • Groovy-Eclipse plugin 2.8
  • JUnit 4.8.2
Kaypro II
  • 3,210
  • 8
  • 30
  • 41
  • Have you also tried @Unroll at the class level instead of method? – dmahapatro Mar 03 '14 at 23:38
  • Yes. It doesn't matter if the @Unroll is at the class or method level, the Eclipse JUnit view still shows the same thing. – Kaypro II Mar 03 '14 at 23:43
  • I see a related [bug in eclipse](https://bugs.eclipse.org/bugs/show_bug.cgi?id=343129). May be that's the cause. – dmahapatro Mar 04 '14 at 01:39
  • Spock hits that eclipse bug too (if you use spaces), but the tests still show up as unrooted for me even if I remove the spaces from their names. – Kaypro II Mar 04 '14 at 04:56
  • I've submitted an Eclipse bug report for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429606. Please vote for it if you want to see this fixed. – Kaypro II Mar 04 '14 at 21:42

1 Answers1

8

It's a well known problem that arises because Spock can't (via its JUnit facade) tell Eclipse upfront how many test methods will get run, and what their names will be. (In data-driven tests, both of these aspects are dynamic. What gets reported to Eclipse upfront is the same as when @Unroll isn't used. Eclipse gets confused when correlating this with what gets reported during the test run.)

I can't think of a good way to solve this problem on Spock's side. I've considered approaches such as adding some ugly heuristics or executing tests twice when running inside Eclipse, but none of them were convincing. A more desirable solution would be to improve the Eclipse JUnit plugin to better handle this situation, which can also arise in many other JUnit compatible test frameworks.

If you can't live with the current output, here are some steps you could take:

  • File an improvement request in the Eclipse issue tracker, and ask everyone on the Spock forum to vote for it.
  • Don't use @Unroll. (It only affects reporting, not execution. One reason why it's opt-in is that some IDEs have problems with it.)
  • Switch to IntelliJ IDEA, which offers significantly better Groovy, JUnit, and Spock support than Eclipse.
  • Blame your coworker for introducing Spock. :-)
Peter Niederwieser
  • 121,412
  • 21
  • 324
  • 259
  • Thanks for your reply. I decided to submit a bug report to the Eclipse project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429606 – Kaypro II Mar 04 '14 at 21:39
  • I bet OP will end up with sponsoring a lunch for his coworker if he blames about introducing Spock. ;) – dmahapatro Mar 04 '14 at 21:47
  • I recommend to formulate the improvement request in more general terms (e.g. "Better test tree output when static and runtime `Description`s don't match"), as it isn't specific to Spock. – Peter Niederwieser Mar 05 '14 at 09:05
  • Do you think you could add a comment in the bug report with that detail yourself? I don't know enough about this to weigh in authoritatively about what the actual issue is, but you do. – Kaypro II Mar 05 '14 at 22:10