I was using JUnit for my TDD in Java and noticed there are two components to download from JUnit.org. First of all, I thought I need JUnit component and downloaded, installed. When I compiled and tried to run my test, it was complaining about Hamcrest classes are not found. So I had to download this one again from their homepage.
So, out of curiosity, why the heck would we need two downloads for one purpose usage from the beginning? Does anyone know why hamcrest core is separate from JUnit, even though it is used by JUnit?
Thanks,
Javabug
JUnit uses Hamcrest. In the past JUnit was embedding the Hamcrest classes which lead to problems, as the projects were evolving in different cycles. In recent JUnit versions (if I'm not wrong, since 4.11) this has been changed and Hamcrest is not embedded. So if you add JUnit as dependency to your project (Maven, Gradle, etc) you will implicit get a dependency to Hamcrest.
I believe this issue on Hamcrest is somehow related to that splitting. https://github.com/hamcrest/JavaHamcrest/issues/92
The class org.junit.Assert has a dependency on Hamcrest core library. As it is part of the static method signature assertThat(), it has to be on the classpath.
If you won't like to use it, a test runtime dependency on hamcrest-core should work, if you want to use it, I recommend a test compile dependency on hamcrest-library (using maven instead of gradle it's all scope test).
There is no transient dependency to be more flexible to upgrade Hamcrest. Btw also Mockito has a Hamcrest dependency. Read more about Understanding Dependencies.
Actually, you want to use as much of the "hamcrest" stuff as possible.
Have a look at assertThat, which makes heavy use of hamcrest matcher classes.
Seriously: I am only using assertThat in my testy by now; and I never ever regretted doing so and abandoning all those other asserts altogether.
Related
I have an application where I want to upgrade a library from an old version to a new version (Kafka client 0.8 to 0.10). Unfortunately the the new version introduces a breaking change which forced me to fix a broken unit test by using the new method signatures.
This works fine but due to the major upgrade I want to support both versions of the library using separate build profiles - one for 0.8 and one for 0.10. I know how to do that for the dependencies themselves but what's the proper way to include a different test file depending on the build profile? Is this even the right way to approach it?
Ideally I'd be able to write the unit test to work in both versions but I haven't been able to figure out how to just yet, or whether it's even possible.
You could set different test source directories in your profiles:
<properties>
<project.build.testSourceDirectory>src/test/v010</project.build.testSourceDirectory>
</properties>
I know how to do that for the dependencies themselves but what's the
proper way to include a different test file depending on the build
profile?
You could use JUnit test categories. You'll probably have to upgrade the version of maven-surefire-plugin as well.
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 making my first Java EE project and can't figure how to test my EJB. I've read that Arquillian is really useful to do integration tests, but it seems like using it without Maven is difficult. Could someone tell me if there is a way to use it or a tutorial?
Are you using any sort of dependency management tool, eg Ivy? I really recommend using one, since it makes things much easier.
That said, Arquillian does not use Maven itself, so you can use it without Maven. You will just have to figure out which dependencies you need. You can either work it out by just looking at the Maven POM files, or you could start with a sample Maven based setup and use the maven-dependency-plugin to export the libraries you need. See also https://gist.github.com/mojavelinux/2363038.
Personally I would recommend to just use a dependency management tool, be it Maven or Ivy.
I am using RHEL 5. I want to be able to write a basic Java class, write corresponding test methods using testNG and be able to say something like "mvn install" which will run test cases and install the built jar.
Is there something called maven plugin to support testNG on RHEL? or there is no such thing and above can be achieved by default on linux. ALso how?
The usual maven plugin for testing, the maven-surefire-plugin, handles testng as well as junit.
There are a number of plugins for Maven that will auto-run your tests. I would suggest starting with an IDE solution, such as one provided by the Spring STS eclipse-based suite, which has pre-built project templates, including *.pom files already set up.
If you are looking to do more than that "out of the box" functionality, reading through the Maven docs and perhaps a book would probably be a good idea. In general, whenever you have a really powerful and flexible tool like Maven, things can get complicated really fast, so having a solid understanding is critical to be able to use the tool successfully.
I have a Maven-managed project that uses Mockito mocking in its unit tests. I can run all the tests within a Maven build, and they run without error (and pass!). However, if I right-click a single test function, and choose "Run As -> JUnit Test", I get an exception java.lang.NoSuchMethodError: org.mockito.Mockito.doAnswer(Lorg/mockito/stubbing/Answer;)Lorg/mockito/stubbing/Stubber;. Of course, the "missing" method is there if I look at the sources, and like I said the tests compile and run from the command line.
Best I can think of is if Eclipse is trying to "help" me by providing an outdated Mockito artifact (I'm using 1.8.5 in my Maven dependencies) for the JUnit plugin, akin to how the Maven plugin can stick you with an oddball version of the Maven runtime for certain tasks.
Is this the problem? Is it something else? Can I fix this?
ETA: Apparently this may relate to a known issue. There's a good chance that it stems from having multiple versions of Mockito in my classpath (thanks, Maven :-/ ). I seem to have my house in order -- Eclipse can run the tests now -- but unfortunately the bug has bitten my Hudson. I have to track down how to remove the old JAR from the classpath there as well.
Make sure the unit-test classpath has the correct mockito. You can check this from the run dialog. Btw, Eclipse does not ship with mockito, so perhaps you are having two versions of it. Take a look at your maven dependency graph and search for duplicates.
I had the similar problem and I found that I had both "mockito-all 1.8.x" and "mockito-core 1.9.5" in my classpath. I was supposed to use only 1.9 but somehow eclipse was putting 1.8 before 1.9.5 in the classpath. I removed 1.8.x and it worked ;)