Add junit-output-to option

[nberger]

When present, it uses clojure.test.junit to output a junit formatted xml file in the junit-output-to directory for each test ns.

Output to stdout will be the same as if the option was not present.

Part of #9

[nberger]

The build should be green once #12 is merged

[nberger]

I'll change junit-output-to to be taken as a directory where an xml file will be created for each ns, instead of being the one xml file that will be used for each ns (which in fact is being overwritten for each ns right now...)

[nberger]

Rebased to master

[nberger]

Rebased to master.

@alandipert: Let me know if you want me to squash the two commits into one.

[nberger]

@alandipert: junit-output-to is an asset path in the fileset now. How does it look?

[nberger]

I have the feeling that passing the absolute path of the tmp-dir to the pod is not a good usage of the fileset, and thus the files might be missing from the output dir... But how should I do it? I can't find an example of writing to a tmp-dir from a pod. I'll keep looking though, but any help will be appreciated

[alandipert]

The general pattern is, the caller creates a tmp-dir and passes the path to
pod machinery. Pod machinery puts files in the place, the caller adds
directory to fileset. Does that make sense?

On Tue, Oct 27, 2015 at 6:18 PM, Nicolás Berger notifications@github.com
wrote:

I have the feeling that passing the absolute path of the tmp-dir to the
pod is not a good usage of the fileset, and thus the files might be missing
from the output dir... But how should I do it? I can't find an example of
writing to a tmp-dir from a pod. I'll keep looking though, but any help
will be appreciated

—
Reply to this email directly or view it on GitHub
#11 (comment).

[nberger]

Thanks, makes sense. I understand that's exactly what I'm doing. The issue now is that when there is a test failure, the task will throw even before getting to the commit! call, so the xml output files never get to the target-path.

Any idea?

[nberger]

Well, I guess I can call commit! before the throw... trying to do that now...

[nberger]

Done, but still doesn't work, because target-path is not created at all. So, I understand that an exception stops everything and target-path is not created in that case. So, we can't output the xml files to the fileset, or we need to find another way to signal that the tests have failed.

[nberger]

Just added some commits that make this to work by using the new target boot task. One gotcha though: it doesn't work on boot 2.5.0 (target is not synced on test errors/failures, I don't know why), but works fine on 2.5.1 and 2.5.2

Includes a refactoring that extracts a run-tests task which runs the tests and saves the test summary as metadata in the fileset (in a new clojure.test.result.edn file created for this purpose, is there a better place where to assoc this metadata?) and then the test task calls that task, syncs to target when needed (that's it junit output is enabled) and then throws an exception if there where test errors or failures.

Let me know what you think about this new version @alandipert. Bumping dependency to boot 2.5.1 might be an issue... Also if you want me to extract the run-tests refactoring into a separate and smaller PR I can do that.

[nberger]

Rebased to master & squashed into more reasonable commits (as agreed with @micha in slack). Also added two changes:

1. Save the metadata right in the fileset instead of in a separate file (so clojure.test.result.edn is not being created anymore)
2. Added a fix to avoid the test counters to be reported multiplied by 2. This was caused by having both junit report fn and the default test report fn incrementing counters. As we call both report functions (junit fn to generate the xml files, the default report fn to have the default behavior: output test failures to stdout, etc) and both take care of incrementing counters, the counters ended being multiplied by 2. The fix was to bind a separate report counters map when calling the junit report fn in https://github.com/adzerk-oss/boot-test/pull/11/files#diff-ab4d298f97d69f8e1e711ca674f00628R32.