Issues running yatspec from a maven module

[Alberto Faci]

Hello,

We've started using yatspec in my project and I have had to do a couple of tweaks to get it working. The project is a maven project with 10 modules or so. The parent has pom packaging while the modules have jar packaging. My acceptance test module (which uses yatspec) was working fine when running "mvn install" from the module directory. However, the index.html file would was missing when running from the parent project.

After debugging, the reason was that the method TestParser.workingDirectory() was resolving to "." inside maven. TotallyLazy´s Sequences.recursiveFiles() was considering that dot to mean the project where the mvn command was run from. i.e. it was scanning the whole project (rather than just the module) to find the test files. On the other hand, when reading the files from the yatspec side, the "." was interpreted as the maven module. Therefore it was trying to read files from the following location:   c:/workspace/myProject/myModule/./myModule/src/test/java....... which failed obviously.

The fix I have put locally is to use the cannonical path straight away and forget about relative dots, in case the system property user.dir is set to a relative path.

TestParser.java
    private static Option<URL> getJavaSourceFromFileSystem(Class<?> aClass) throws IOException {
        File absoluteWorkingDirectory = new File(workingDirectory().getCanonicalPath());
        return isObject(aClass) ? NO_URL : recursiveFiles(absoluteWorkingDirectory).find(where(path(), endsWith(toJavaPath(aClass)))).map(toURL());
    }

Has anyone had issues with this? Is there any better solution?

Regards,
Alberto

PS. I have found another issue when running yatspec tests in parallel from the maven surefire plugin and I have patched the SpecRunner to support concurrency, but I will post it in a different thread.

[Daniel Worthington-Bodart]

I've recently fixed totallylazy working directory to use 'user.dir' so
it's absolute by default, so might just upgrade that.

Also the preferred way to find the source files is to just include
them in the class path, rather than looking on the file system as this
makes it completely portable and doesn't get affected by weird project
structures and cyclic symbolic links that we sometimes see in project
folders. Best is just make you test jar include the sources.

On the concurrency side, if you have a better way of writing the index
files, I'm all ears as it's very in efficient at the moment. Junit
does not provide and event to hook into at the end that actually works
in all environements (maven, ant, IntelliJ Eclipse etc) The docs say
it does but we have never seen it fire.

Dan

[Alberto Faci]

Hi Dan,

Thanks for your reply. That fix to use "user.dir" is it on yatspec-201 internal totallylazy clases?
I see they are based on totallylazy-535, right? The latest totallylazy does user the user.dir. I guess that's what you mean.

Anyway, adding the test source directory to the classpath is the way to go and now it works perfectly fine (in my case using a additionalClasspathElement on the maven surefire plugin) . Thanks for that.

On the concurrency side of things there are 2 potential problems.

• The currentScenario field not being threadsafe on SpecRunner.java.(one test failure was being added to different test classes). I solved it creating a Map<String, Scenario> where the key is the method name. I will check other alternatives.
  
• Regarding the index report, Tests results get added to the Index object in unpredictible order in HtmlIndexRenderer. The renderer splits them in packages properly. However, the tests within the same package don't appear in alphabetical order on the report as you would expect.
  

Regards,
Alberto

[Nick Barrett]

Hi there Alberto - Wow this original post was done ages ago, so I'm waaay behind the curve here!

I've just started using Yatspec (217) on my project and I am also using the maven-surefire-plugin. I too have noticed that there appears to be a thread-saftey issue that manifests obviously when there are test failures - the number of highlighted fails seems greater than the number of fails that actually happened and also the exception from one test is rendered in another! Was there ever a fixed version of the SpecRunner produced as I think I'm using the latest Yatspec and still having problems.

Thanks in advance!

Nick