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(...)
Related
I find very little reason to use EasyMock, with Mockito available.
However, when I have a class with a million dependencies, I prefer annotation syntax - Mockito #Mock/#InjectMocks or EasyMock #Mock/#TestSubject.
As far as I can tell from poking around, with Mockito I have to use MockitoJUnitRunner, or MockitoAnnotations.
MockitoJUnitRunner supports field injection, but as far as I can see, the latter requires constructor/setter injection. When I need to use a different runner, and don't want to add constructors or setters to my production code for testing, I seem to be stuck with EasyMockRule.
Does Mockito provide an equivalent, to allow non-Mockito runners and field injection?
Thank you
You can use org.mockito.junit.MockitoJunit.rule().
#Rule
public final MethodRule mockito = MockitoJunit.rule();
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 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
How does AtUnit fare with respect to unit testing using DI and guice ?. Please share your experiences.
I have found it works rather well and is very simple to use. In my case though, after a while, I decided to revert back to my old pattern of rarely using DI in unit tests, unless I'm testing something functional. I found that all the extras that AtUnit was providing were simply not being used in my situation.
In the cases where I do use Guice in tests, my unit test class extends AbstractModule and I do the Guice initialization etc manually in my #Before method. I suppose using AtUnit here would be pretty much the same with the exception that all my manual stuff would mostly disappear.
Are there any unit testing solutions for Flex? or actionscript 3?
If so, what are their features? Any UI testing abilities? Functional testing? Any pointers, examples, libraries or tools that you can share?
FlexUnit is pretty awesome - http://opensource.adobe.com/wiki/display/flexunit/FlexUnit
Also ASUnit - http://asunit.org
They are both pretty similiar and both haven taken quite a bit from frameworks like JUnit.
FlexMonkey (http://code.google.com/p/flexmonkey/) although I haven't used it myself seems to do UI unit testing.
I just found fluint, and it was a great unit testing library, better than both Flexunit and ASUnit imho. It handles asynchronous testing really nice.
I can confirm that FlexMonkey indeed does UI unit testing. It provides record/playback of UI interactions and generates FlexUnit test cases.
Check it out at http://flexmonkey.googlecode.com
I would recommend FlexUnit, too... and you also have a look at Visual FlexUnit.
A few days before I found the RIATest-Tool, but I haven't tried it yet.
I'd recommend fluint simply due to it having a more active developer base (and it's improved support of testing asynchronous code). Also, if you are after mocking/stubs there is asmock (a dynamic mocking framework) and mock-as3 (a static mocking framework).
For asynchronous unit testing dpUint is pretty useful. However FlexUnit is the way to go, if you wish to integrate unit testing with a Maven build. Asynchronous testing (e.g. Cairngorm events) can also be done with FlexUnit, but is not as elegant as with dpUint.
Try mockito for flex http://bitbucket.org/loomis/mockito-flex