Question - Eclipse Junit Runner Nesting Limit

[gstu...@learndirect.co.uk]

Hello,
I have noticed that when running tests via Maven the Junit test report seems to nest as deeply as the corresponding tests (which is expected).
However, our testers normally use the Eclipse Junit runner, rather than Maven. When running from Eclipse the runner only nests the results to 5 levels. This makes it difficult to see exactly which line failed. This seems to be hard-coded into substeps-runner: com.technophobia.substeps.runner.EclipseDescriptionProvider.

In method: 

private Description buildDescription(final IExecutionNode node, final Map<Long, Description> descriptionMap,

            final DescriptorStatus status)

I can see the line:

if (nodeWithChildren.hasChildren() && nodeWithChildren.getDepth() < 5) {

Please can you tell me if this hard-coded nesting limit was put in place to overcome issues with Eclipse and the Junit runner? I have tried installing this project locally and removing the limit, and at first glance it seems to work without the limit. Are you aware of issues that required this limit?

I replaced the above with:

if (nodeWithChildren.hasChildren()) {

Many thanks,
Gary

[Ian Moore]

Hi Gary,

Oh dear!  It looks like you've uncovered a magic number that maybe had a purpose that perhaps doesn't anymore! 

Basically, in order to quickly get tests running with a JunitRunner, you need to provide a description, essentially a String.  This string has to be unique otherwise with the same substep potentially called repeatedly in different scenarios you get odd behaviour in eclipse in terms of the sequence of tests being executed / passed / failed etc.  Hence the need to generate the 1-1-1... type of id as a prefix.

I suspect that I might have put the limit of 5 in to prevent that id from becoming unwieldy.  I would suggest that if it all works as you'd expect without that limit, then it should be ok.  We'll remove it in the next release.  The class is only used by the eclipse plugin and that is only in the short term - trying to shoe-horn functionality into what is essentially a JUnit framework is extremely limiting - as you can see from the code we've had to open up JUnit's private Description constructor which is just nasty, and the prefixing of the string with the generated id isn't much better either.

We are currently working on breaking out of this restriction with a new runner and a new bespoke view that will allow greater flexibility in terms of what it can do!  Watch this space!  

Thanks for the feedback and finding that bug!
Cheers
Ian