We Keep Coding

In a java maven or gradle project, can we write test cases in main package rather than in test package?

How do we make mvn build or Gradle build to take test cases from the main package if we have written test cases in the main package?

In gradle you just redefine the main and test sourceSets with filters in your build.gradle file to exclude / include the test files in the specific phase of the build.
For example the file named LibraryTest.java will be compiled and executed only during the test phase.
sourceSets {
main {
java {
srcDirs = ['src/main/java']
exclude '**/*Test.java'
}
}
test {
java {
srcDirs = ["src/main/java"]
include '**/*Test.java'
}
}
}

you can write your test cases where ever you want, BUT!
It is not a recommended practice, so if you are using maven/gradle - they will give you dedicated folder/path for writing test cases.
The reason why it is not recommended - is maven/gradle provides lot of plugins which will help you to run your test cases, generate reports for those test cases, control the build if test cases fails.
All these plugins will look up at the default path, so if you decide to use a different path rather than default - you need to change the path for test cases in all your plugin.
so if you choose to use your own path for test resources, you are just adding overhead of additional configuration changes.

Package tests for execution in gradle

I have a gradle project that contains a suit of tests, that can be launched with a command:
gradlew clean :mymodule:test
I need to build a jar, that can be executed in the same way and launch tests. I found instruction for creating a jar of test binaries here Creating a Jar of test binaries - Gradle.
task packageTests(type: Jar) {
classifier = 'tests'
from sourceSets.test.output
}
However the resulting jar contains only test classes and resources, no dependent libraries or main application source code.
How can I create an executable test jar?

If I were you, I wouldn't use classifier='tests' as that is usually reserved for a jar containing test classes without dependencies. Possibly uber-tests or fat-tests is better as uber-jar and fat-jar are common names given to this type of jar. You could do something like
task uberTestJar(type: Jar) {
dependsOn testClasses
classifier = 'uber-tests'
sourceSets.main.output.each {
from it
}
sourceSets.test.output.each {
from it
}
configurations.testRuntime.each { File f ->
if (f.name.endsWith('.jar')) {
from zipTree(f)
} else {
from f
}
}
}
There's also the shadow jar plugin

Gradle - running a junit test not finding my xml file

I'm having a simple junit test task.
task testSanity(type: Test, dependsOn: testClasses) {
def springInstrumentJarPath = project.configurations.compile.find { it.name.startsWith("spring- instrument") }
jvmArgs '-javaagent:' + springInstrumentJarPath
exclude '**/*TimeBaseTest*'
exclude '**/*SuiteTests*'
}
Problem is i added a new xml file for my ehcache at:
/src/main/webapp/WEB-INF/classes/ehcache.xml
And all my test fails since junit is not able to find the file.
How can I define this in the gradle task?
Thanks.

src/main/webapp should only contain files that aren't used from Java code (more precisely, files that aren't loaded by a class loader). Java resources should instead go into src/main/resources. Hence, moving the file to src/main/resources/ehcache.xml should solve the problem.

Gradle and JaCoCo: instrument classes from a separate subproject

I have a legacy application that has a unit test module that's separate from the application modules. I'm converting the project to use Gradle and the structure looks like this:
/root
/module1
/module2
...
/moduleN
/test
where the test module executes tests for module1 through moduleN (and depends on them). I know this isn't a very good practice as it kinda defeats the purpose of unit tests but as all know, legacy code is always a headache to work with.
So before I start refactoring the code so that each module has its own unit tests (which means disassembling the test module in a sensible way, i.e., a lot of work) I wanted to find a temporary solution to get the correct code coverage, i.e., have JaCoCo instrument all the classes from module1, ..., moduleN instead of just module test.
Is there a way to tell JaCoCo to instrument classes from other modules?

To include coverage results from subprojects "module*" in the "test" project, you might want to try something like this in your build.gradle from the test project:
// [EDIT] - 'afterEvaluate' NOK, use 'gradle.projectsEvaluated' instead (see comments)
// afterEvaluate {
gradle.projectsEvaluated {
// include src from all dependent projects (compile dependency) in JaCoCo test report
jacocoTestReport {
// get all projects we have a (compile) dependency on
def projs = configurations.compile.getAllDependencies().withType(ProjectDependency).collect{it.getDependencyProject()}
projs.each {
additionalSourceDirs files(it.sourceSets.main.java.srcDirs)
additionalClassDirs files(it.sourceSets.main.output)
}
}
}

Run JUnit tests from a dependency jar in Eclipse

I have some JUnit tests that contained in a .jar that is intended to be used as a library. The library contains some tests that should be run whenever the library is used in another project.
However when I create a new project using the library and run JUnit on it in Eclipse then the tests in the dependency .jar don't run / don't get detected by the JUnit test runner. I get the message:
No tests found with test runner 'JUnit 4'.
Is there a way I can configure the dependency .jar so that the tests will run alongside any tests that might be contained in the main project?
Basically I want the dependency .jar to "export" the tests to whatever projects it is used in.
I'm using Eclipse Juno, JUnit 4.10, and Maven for the dependency management.
EDIT:
The point of this library is to be able to help test projects that use it - i.e. it runs some specialised tests. This is why I want to be able to import the library .jar and have it contribute the extra tests to the importing project.

You can try Maven Surefire.
In some cases it would be useful to have a set of tests that run with various dependency configurations. One way to accomplish this would be to have a single project that contains the unit tests and generates a test jar. Several test configuration projects could then consume the unit tests and run them with different dependency sets. The problem is that there is no easy way to run tests in a dependency jar. The Surefire plugin should have a configuration to allow me to run all or a set of unit tests contained in a dependency jar.
This can be done as follows (Junit 3):
Ensure test jar contains a class which has a static suite() method
import junit.framework.Test;
import junit.framework.TestSuite;
public class AllTests {
public static Test suite()
{
TestSuite suite = new TestSuite( "All Tests");
suite.addTestSuite(TestOne.class);
suite.addTestSuite(TestTwo.class);
return suite;
}
}
Then in the project using the test-jar dependency:
create a TestCase:
package org.melati.example.contacts;
import org.melati.poem.AllExportedTests;
import junit.framework.Test;
import junit.framework.TestCase;
public class PoemTest extends TestCase {
public static Test suite()
{
return AllExportedTests.suite();
}
}
Now the tests will be found.

I think that making a library of unit tests (#Test annotated methods) is a bad idea. However, making a library of reusable test components is a good one. We've done this in a few open source projects, and you can take a look how it works.
One Maven module exports test components (we call them "mocks"), from src/mock/java directory. Exported artifact has -mock classifier. See rexsl/pom.xml (pay attention to highlighted lines).
Mock artifacts are being deployed to Maven Central, together with usual artifacts: http://repo1.maven.org/maven2/com/rexsl/rexsl-core/0.3.8/ (pay attention to ...-mock.jar files)
Modules that need that mocks can include them as usual artifacts, for example rexsl-core/pom.xml (see highlighted lines):
Then, in your unit tests just use the classes from that mock libraries, like regular builders of mocks, for example: BulkHttpFeederTest
That's how you can make your test artifacts reusable, in an elegant way. Hope it helps.

#Mikera,
I find that this may help you. Just extend the Testcase Class to one of your java classes in project and you can run that particular class to run it as a JUnit Test.

I am not sure that this is desirable - On the one hand, if you use a jar, its behaviour might be influenced by the external context, e.g. other libraries in the classpath. From inside the jar, there is no simple way to analyse this context and to adjust the tests accordingly. On the other hand, if you write and compile a library, you should test it before packaging it as a jar. You might even want to not include your tests.
If it is really important to you to run the tests again, I would be interested in what could make them fail without changing the jar. In that case, however, you might want to extend the testrunner. As far as I know it uses reflection. You can quite easily load jars in a classloader and go through all their classes. By reflection you can identify the test classes and assemble testsuites. You could look into the testrunner for an example. Still, you would need to start this process from outside, e.g. from inside one of your test classes in the client project. Here, QATest's approach might be helpful: By providing an overriden version of testsuite or testrunner, you could automate this - if the client uses your overridden API.
Let me know if this rather costly approach seems to be applicable in your scenario and I can provide code examples.

Why should the user of the jar run the test cases inside the jar!!! When the jar is packaged and delivered, it means that the unit tests are run successfully.
Typically, the jar itself should be either treated as a separate project or as one of the modules. In both the cases, unit test cases are run before its delivered.