How to integrate Concordion with a different JVM test runner?

[Jakub Holý]

Hello!

I would like to extend Concordion to make it possible to write tests in Clojure's `clojure.test`, which has nothing to do with JUnit (though it can produce JUnit output XML). I can easily expose static methods for Concordion's Java code to call.

Is that something that could be feasible without too much effort? Or is C. too tightly coupled with JUnit? Where should I look? Could that be just an extension?

Thank you very much for any guidance!

Best Regards, Jakub Holy

[Jakub Holý]

I guess I just replicate https://github.com/concordion/concordion-parallel-run-extension but instead of falling back on the default runner, I will make my own https://github.com/concordion/concordion/blob/master/src/main/java/org/concordion/api/Runner.java doing the same stuff as https://github.com/concordion/concordion/blob/master/src/main/java/org/concordion/internal/runner/DefaultConcordionRunner.java but using clojure.test instead of JUnit. Right?

--
You received this message because you are subscribed to a topic in the Google Groups "concordion-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/concordion-dev/EUviKByEOEA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to concordion-de...@googlegroups.com.
To post to this group, send email to concord...@googlegroups.com.
Visit this group at https://groups.google.com/group/concordion-dev.
To view this discussion on the web, visit https://groups.google.com/d/msgid/concordion-dev/0f50458f-d4c1-4de2-9e41-17afd3857dc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Charman]

Hi Jakub

This bit of the codebase is a bit messy. We made a few changes in 2.0.0 to tidy it up, and might need to go further with the JUnit5 integration. Feel free to propose changes if you get clojure.test working!

There's 2 places where the test runner is called:

1. Directly when invoking a test - eg. the JUnit4 ConcordionRunner, the JUnit3 ConcordionTestCase. These call FixtureRunner which calls ConcordionBuilder. You're likely to want to create something similar to ConcordionTestCase and FixtureRunner, then reuse ConcordionBuilder - eg, see Mark Derricutt's basic TestNG runner. This was created way back for Concordion 1.3.1 - you'll need to implement the Fixture and FixtureDeclarations interfaces from Concordion 2.0.0 onwards.
2. Indirectly, from a Concordion Suite, when the concordion:run command is encountered in a specification, spawning a new test within a test. If you want to support the concordion:run command, this is where the Runner / DefaultConcordionRunner comes in. By default ConcordionBuilder plugs in a SystemPropertiesRunnerFactory which lets you override the Runner with a system property. If this doesn't suit, we could open up withRunnerFactory as an extension method - rather than overriding RunStrategy which is designed to cater for different strategies for invoking the Runner.

I hope that helps. Let us know what questions you have?

Nigel

On Friday, 12 April 2019 19:58:46 UTC+12, Jakub Holý wrote:

I guess I just replicate https://github.com/concordion/concordion-parallel-run-extension but instead of falling back on the default runner, I will make my own https://github.com/concordion/concordion/blob/master/src/main/java/org/concordion/api/Runner.java doing the same stuff as https://github.com/concordion/concordion/blob/master/src/main/java/org/concordion/internal/runner/DefaultConcordionRunner.java but using clojure.test instead of JUnit. Right?