I am not sure how to migrate this since DataProviderRunner.class which is class that relay on to junit4.
(DataProviderRunner.class is from
import com.tngtech.java.junit.dataprovider.DataProviderRunner;
I know that #RunWith is replaced with #ExtendWith
Has anyone done a similar thing and how?
https://github.com/TNG/junit-dataprovider comes with support for Jupiter, which is JUnit 5‘s default engine. Use this.
Here’s the documentation: https://github.com/TNG/junit-dataprovider/wiki/Migration-guides#migration-to-junit5
Related
I wrote a plugin for Solr which contains new stream expressions.
Now, I'm trying to understand what is the best way to write them unit tests:
Unit tests which need to include creation of collections in Solr, so I will be able to check if my new stream expressions return me the right data they suppose.
I saw over the web that there is a class called "SolrTestCaseJ4", but I didn't find how to use it for creating new collections in Solr and add them data and so on...
Can you please recommend me which class may I use for that purpose or any other way to test my new classes?
BTW, we are using Solr 7.1 in cloud mode and JUnit4.
Thanks in advance.
you could use MiniSolrCloudCluster
Here is an example how to create collections (all for unit test):
https://github.com/lucidworks/solr-hadoop-common/blob/159cce044c1907e646c2644083096150d27c5fd2/solr-hadoop-testbase/src/main/java/com/lucidworks/hadoop/utils/SolrCloudClusterSupport.java#L132
Eventually I found a better class, which simplifies everything and implements more functionality than MiniSolrCloudCluster (actually it contains MiniSolrCloudCluster inside it as a member).
This class called SolrCloudTestCase, and as you can see here, even Solr's source code uses it in their own unit tests.
I read that Mockito 2 doesn't use CGLIB/proxy any more but instead uses ByteBuddy for mock creation. Does that mean that from now on it is possible to mock static methods and private methods?
No, you can't (see their documentation here; I am sure they would mention that).
So, PowerMock(ito) and JMockit are the two mocking frameworks that support mocking static methods.
But, some personal opinion: one should nonetheless prefer to use Mockito instead PowerMock(ito); simply by writing code that can be tested with Mockito; and that doesn't need PowerMock. What I mean is: when you write your own code and you think you need to mock static calls; then you are writing hard to test code.
The answer is not to look to powerful mocking frameworks; but to write easy to test code instead. You can have a look into these videos to learn how to do that.
Finally: don't think that PowerMockito is a good alternative. Mockito is right now at version 2.79 (as of March 2017). But when you have a look at PowerMockito; you will find that it ships with some Mockito 2.0.42 beta something - because the PowerMockito folks can't get their tool working with any newer version of Mockito. And that is a shame, because those newer Mockito versions have a lot of interesting features.
I wrote an extension of Mockito 2 which uses AspectJ to allow mocking even things like static/private/final methods, with one easy lambda-based syntax, for example:
when(() -> YourClass.staticMethodToCall(...)).thenReturn(...)
Is it possible apply JavadocMethod checker only on methods in interface? (not in implementation classes)
We had plan to implement it also, keep at eye on issue, not sure when we fix it, or welcome to provide patch we already have full infrastructure for development.
If you are using Java 6, you can annotate the implementing method with #Override, which will tell the JavadocMethod checker not to require a Javadoc comment. Quoting the JavadocMethod docs:
Javadoc is not required on a method that is tagged with the #Override annotation.
The documentation continues stating that you need Java 6. In Java 5, you can still use {#inheritdoc}, which is better than nothing:
However under Java 5 it is not possible to mark a method required for an interface (this was corrected under Java 6). Hence Checkstyle supports using the convention of using a single {#inheritDoc} tag instead of all the other tags.
The built-in Eclipse code formatter can automatically add the #Override annotations for you, so this should be pretty much what you need.
I'm currently working on a class, dealing with network issues. Using JUnit 3.8.1 and having a hardware device, that's not always around to test against, I'd like to conditionally suppress individual tests. Is there a way to achive this with a simple annotation like #if(!gatewayAvailable) -> test's suppressed?
Thanx for any pointers, marcus
There is no such feature in JUnit 3.8.1. You have to use JUnit4 and its Assume class.
I'm following this guide http://javaeenotes.blogspot.com/2011/06/short-introduction-to-jmock.html
I've received the error
java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer information does not match signer information of other classes in the same package.
In the guide the author says:
The solution is make sure the jMock libraries are included before the
standard jUnit libraries in the build path.
What makes up the "standard jmock libraries" and the "junit libraries"?
Junit only has one jar so that's easy, but jmock comes with over 10 different jars.
I've been using: j-unit4.10, jmock-2.5, hamrest-core and hamcrest-library
What are the hamcrest core and library classes for?
i'm a committer on both libraries. JMock depends on hamcrest to help it decide whether an call to an object is expected. I suggest just using the hamcrest-all jar. The split between hamcrest core and library was to separate the fundamental behaviour of matching and reporting differences from a convenient implementations of the most common cases.
Finally, if you're using hamcrest, I suggest you use the junit-dep jar to avoid clashes with some features of hamcrest that are included in the junit.jar
JUnit is used to do Unit test in order to test your methods. JMock is used to test your program inside a context, You will have to know what you are expecting to send to the context (ENV) and what will answer the context.
JMock use JUnit, that is why, in order to avoid dependency conflicts, you need to include it before JUnit.
The 10 libraries of JMock are kind of add-ons if you need to use JMock script or any other functionnality not available in the JMock core.
You don't need to know about Hamcrest-core library to use JMock. Just follows the guide on the web site (don't use version 1 of JMock) and Organize your libraries in the correct order (JUnit should be last in order to avoid your error)
mock frameworks licke jmock do some black magic behind the scenes
( including, but not limited to runtime byte code manipulation )
to provide mock methods classes and whatever. To be able to do this,
some tweaks in basic junit classes are necessary, and the only way to do this is to
register itself as java agent before JU classes are loaded.
Also, put your mock framework before junit in classpath