How to handle tearDown of JUnit tests (in Gradle) when you have multiple test classes


(Jon Austen) #1

I have a question about how to handle tearDown of JUnit tests (in Gradle) when you have multiple test classes.

Here is the problem:

  1. JUnit doesn’t have a @AfterSuite annotation like TestNG has for test groups. 2. The @AfterClass annotation works fine where all your tests are in one single class but that is not my question. 3. If you have multiple JUnit classes , each with their own set of tests, and all of the classes need to share a

static object of some kind, such as a web browser object, in that case the tearDown in @AfterClass would destroy

the static object between classes which isn’t acceptable for performance reasons. Destroying and recreating an

object over and over again unnecessarily is inefficient.

So, how can Gradle solve this issue for me?

Is the Gradle JUnit Runner capable of something similar to @AfterSuite ?


(Peter Niederwieser) #2

Depending on the kind of work, you can either do it in the build (before/after running a particular test task), or use JUnit test suites (see the JUnit docs).


(Jon Austen) #3

I tried that already but when I ran the JUnit test suite, the Gradle “Runner” still picks up all the other tests classes, therefore running all tests TWICE.

Not sure why the Runner does this.

I was expecting the Runner to “detect there is a suite” and run only the suite.

Also, what if I have more than one suite/group of tests. Is this something that the Gradle Eclipse Tooling plugin is supposed to handle or am I overlooking some way that Gradle itself has that already exists to handle this?

I believe I tried using -Dtest.single

but the Runner still picks up the other tests .

If you are so sure it works, I will try again, it is very possible I have a config problem, but I am not convinced after trying it once already.


(Peter Niederwieser) #4

It’s something that you have to deal with yourself, by declaring one or multiple test tasks which run the suites you want them to run, and nothing else.


(Jon Austen) #5

Thanks Peter. I got it working ( see project here: https://github.com/djangofan/WebDriverHandlingMultipleWindows

)

I have one question though.

I can only get it to work by passing the JVM option to gradle:

-Dtest.single=SuiteName

Is there a programmatic way of doing the same thing in the build.gradle file so that I do not need to pass the option?

I think your earlier comment suggests this is possible.

I want to setup multiple suites and I am unsure of how to configure Gradle for multiple test variations/tasks, each having their own report directory…

Is there an example anywhere?

I am trying this and it isn’t quite working: ’ task groupOneTest(type: Test) {

include ‘**/SuiteOne.class’

testResultsDir = ‘build/test-results/SuiteOne’

testReportDir = ‘build/reports/SuiteOne’ } ’


(Jon Austen) #6

Peter,

Ok, I got it all working finally, and I no longer need to pass that JVM -D option. Here is my code I used for my custom test:

'task groupOneTest(type: Test) {

//include ‘**/SuiteOne.

include ‘**/SuiteOne.class’

testReportDir = file("${reportsDir}/SuiteOne")

testResultsDir = file("${buildDir}/test-results/SuiteOne") }’

Now, the only question I have is:

Is there a way to get the test report to show the Suite classes? Currently, in the test report, if I click on the suite, it just shows the list of all method names in the suite WITHOUT any information about what class each method belongs to.

I’ll open a new thread on this separate topic ( http://forums.gradle.org/gradle/topics/how_can_i_customize_the_report_xml_output_to_have_info_about_junit_test_suites ).