Hey its the first time i use JUnit with Java and i'm not sure how to set it up inside Visual studio Code. I tried to put Junit-4.13.jar inside my a lib file in the root directory but nothing changed. any ideas? I am on MacOS.
There were 2 main issues with this configuration:
JUnit 4 dependency jar was used while in the source code imports from JUnit 5 API were used
Tests resided in the same location as sources, while the dependencies defined via Gradle/Maven for tests limit the scope to src/test/java roots.
In a non-Gradle project the issue was fixed by adding the proper JUnit 5 dependencies to the module.
In the Gradle project the issue was fixed by moving the test class from src/main/java to src/test/java.
Sample Gradle project is available on GitHub.
More details about using JUnit 5 can be found in the official documentation.
Related
I've implemented jacoco to my project some times ago. The implementation is just like described here:
classpath "org.jacoco:org.jacoco.core:0.8.3"
and I have no problem on that. (Let's say this is project 1)
But the thing is whenever I'm exporting the project to .jar file. The second project (let's say project 2) that I use the .jar file gives that error on runtime:
java.lang.NoClassDefFoundError: Failed resolution of: Lorg/jacoco/agent/rt/internal_8ff85ea/Offline;
at
I've tracked the error about the library but in reality I don't want to export anything related to jacoco in project 1, because it seems meaningless to me to have that inside the jar file.
How can I keep jacoco out of the jar file?
Your error is specified in how to prevent jacoco instrumenting production code?. Basically it is explained that JaCoCo provides two ways of performing instrumentation: on the fly and offline. It also describes literally the root of your problem (in bold):
One of such specific scenarios - is execution of tests on Android,
because there is no way to use Java agent on it. So AFAIK Android
Plugin for Gradle, when instructed to measure coverage using JaCoCo,
uses offline instrumentation and therefore requires two types of build
- with coverage and without for release.
So you need to generate the jar for release. Actually in the example you used as baseline, it gives you the solution (with small corrections) to disable testCoverage for the release:
buildTypes {
release {
// Your release part, disable testCoverage
testCoverageEnabled false
}
debug {
//your debug part
//add tests coverage using Jacoco
testCoverageEnabled true
}
}
UPDATE: found this workaround for maven.
Instrumentation should not be done on every build. You do not want to release instrumented code, first because this is bad practice and second code will not run unless jacocoagent.jar is in the classpath.
Try to download and include jacocoagent.jar manually in the classpath (I did not have time to test it).
You can create a separate 'Java Library' module in your project and don't add 'Jacoco' dependencies in that module. You can just keep your core logic, which you want to be exported in that module. When you will build that project, a .jar file will get created in '{module_name}/build/' folder of your project.
You also need to add this new module dependencies in your main module 'app'. And add 'Jacoco' dependencies also in 'app' module.
Let me know, if you need further help.
I'd like to run tests with JUnit 5 on Java 9 modular project in Eclipse, with no Maven, Gradle or all that fancy stuff. So I have src/main/java path where module-info.java and module's packages live and also src/test/java where all the test classes are. Id est business as usual, prior to the Jigsaw module system. I have Eclipse Oxygen.3a (4.7.3a) an Java 10.0.1.
I've seen some video from Eclipse showing, how to add JUnit test to modular project, but this flabbergasted me deeply: they put required keyword into module-info.java of a module, binding it to JUnit module. Is that actually even correct?
I've seen also all these --patch-module/--add-reads solutions (when we're talking about working in a console) and it seems like it's the proper way to do it, but I have no idea, how to achieve that in Eclipse without binding module under test to JUnit module. Is that even possible in Eclipse (without Maven and s.o)?
I tried to solve this problem for quite a while, too. My approach is to add a filter to the source code directory for src/main/java that filters out the module-info.java. This allows to have a different module-info.java in src/test/java. It will be this one that gets copied to the output folder. This way you can run your unit tests from within the IDE and use the other one for the final build. However, you need to keep the content of the one in src/main/java updated yourself.
Right click on the project > Properties > Java Build Path > Source
Select the src/main/java entry, click Edit > Next > Exclusion Patterns > Add
I have an interesting problem. I have two projects, which both depend on different versions of a library. The individual projects cannot change their dependencies, due to version constraints.
So:
Project A depends on lib version 1
Project B depends on lib version 2
lib version 2 is binary compatible with version 1, but has additional functionality so we don't want to update project A to depend on version2.
When running tests that only involve project A, then the class path is perfect, it only contains version 1 of lib.
When running tests that only involve project B, then the class path is perfect, it only contains version 2 of lib.
When running tests that involve both projects A and B, then the class path is broken, as it contains both version 1 and 2 of lib.
Is there any way to say "use this library for compiling only, and don't export for the runtime class path"? This is in some ways related (but opposite) to the exported flag on a JAR file, since that exports it to projects that you depend on as a compile dependency. I want to not export it as a runtime dependency.
When running from the command line this all works fine for us, it is only within Eclipse that we are seeing this problem.
It is possible to specify a classpath for a junit launch configuration via the junit run configuration dialog. See here section "Customizing a Test Configuration": https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-junit.htm
(image from https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-junit.htm)
The new version of the library needs to be added to the classpath before the default element so that during class loading the new library version will be seen first.
After you have configured the correct classpath export the launch configuration to the workspace via Export ... -> Launch Configurations. Then you will be able to run it with right clicking on it and selecting Run as -> <Your Lauch Config name>
our maven repo currently has two versions of mockito, both versions are being pulled in as dependencies to other jars, and each is used in a different child project. Our integration-tests, which are a separate project, use a different version then the unit tests used by our core application.
The mockito versions have changed the signature of a method, making them not backwards computable. Due to the jars that each mockito version is dependent on it isn't easy for me to reconfigure maven to use only one version of mockito for each project.
When I run maven directly, from eclipse or command line, this is not an issue, the correct mockito version is used for each project based off of the pom file. However, when I try to run our unit tests in eclipse I am getting a NoSuchMethodError, which seems to be due to eclipse using the incorrect mockito version. Is there a way to ensure my junit tests use the version of version of mockito I want, aka the one specified in the pom file?
The first thing you should do is declaring mockito as a direct dependency of the modules that use it and not rely on it being drawn in through a transitive dependency. Maven/Eclipse/m2e should first use the version that is declared locally.
If that fails to resolve the problem, in my experience, it can help reordering the dependencies in the POM and checking the Maven Dependencies container in the project explorer or the Dependency Hierarchy tab in the POM editor afterwards to see if the right version is now used. Typically trying to move the problematic dependency either to the first position in the dependency list or to the last position resolves the problem.
Another (possibly additional) option is to add an exclude to that dependency which draws in the "wrong" version of mockito. Again, check the Dependency Hierarchy tab to see where the dependencies are coming from.
Finally, you should save yourself headaches and set up a project-wide dependency management that covers the unit tests in your application as well as the integration tests.
Good luck ;)
In Eclipse, go to your run configuration for your unit test. There is a "Classpath" tab there. You should be able to modify your classpath there to use the proper version of the jar.
I'm developing a project in Eclipse JDT, that has optional dependencies on OSGI - that is, it supports being used as an OSGI bundle, and if it is used as a bundle inside an OSGI environment, it will also reference some classes from OSGI.
Now I want to write JUnit test cases for both running inside OSGI and running without OSGI, included in two different test suites. The OSGI tests are run as JUnit Pulg-in Tests and the Non-OSGI tests should be run as normal JUnit Tests.
Now I have the problem, that I couldn't find any way in Eclipse to exactly specify the classpath for the JUnit Test Run Configuration and exclude the optional OSGI jars.
Is there any way to exclude jars or modify the default classpath for an Eclipse Run Configuration?
If not, does anyone have a suggestion, how one should setup JUnit tests in such a case?
The only solution I was able to find is, to create a jar file from my unit tests and run the tests without OSGI from a different project with the test jar file on the classpath. But I would prefer a more elegant solution, ideally without the necessity of a second test project.
With the help of Gimbys comment, I was able to solve the problem. Although it is not possible in Eclipse to modify the default classpath generated by JDT, it is possible to entirely remove the default classpath and then add your own classpath in the classpath tab of the Runtime Configuration.
To remove the default classpath, one has to select the root entry that is named after the currently run project, and then click on the "remove" button. After that one can add all the jar files and projects that should be loaded in the classpath. The downside of this approach is, that jar files, that are normally provided by Eclipse plugins like e.g. junit.jar, must then also be selected manually (e.g. by adding it to a library folder of the project or by selecting the external jar in the plugins directory of the Eclipse installation folder).
I would suggest that you split up your project in 4 separate projects:
Logic: This package contains all the logic, so basically what your program/plug-in does
Logic.plugin: This Project resembles a Plugin-Project (OSGI-Bundle). This project contains only configurations needed for your plugin and everything dependent on osgi. It has a dependency on your Logic Project.
Logic.plugin.test: All the test cases for your osgi bundle. It is the normal plugin approach to split up logic and test cases
Logic.cli: This project contains the command line interface (or whatever your alternate application is). This also depends on the Logic project.
If your CLI project is only very small you may merge it with the Logic project.