I'm trying to use PowerMock as a library in another application. Is there a way to use it to mock a static method call without using annotations (I'm in Clojure which doesn't really do annotations)
According to powermock support and this blog, I guess there is no way to avoid annotations in test. I guess we need the #PrepareForTest(StaticClass.class) however. So I believe it is not possible to avoid #PrepareForTest atleast. May be I am wrong, but just thought of sharing what I found.
In fact, it's possible, although the way to final solution is painful.
PowerMock runner just initializes test environment in different classloader, in which the classes specified in PrepareForTest annotation are tweaked by Javassist. So assumed you mimic the work of the classloader and call Javassist by yourself, you can achieve the same effect.
As an example, I utilized PowerMock (internals without annotations) to discover name of method for given method reference. Further info can be found on my blog (in Czech, with working examples). I emphasize such an usage is only experimental and not suitable for production usage.
Related
As per my understanding, these annotations used for methods with an access modifier that allows method invocation from another class for unit testing
#VisibleForTesting - com.google.common.annotations.VisibleForTesting
#TestOnly - org.jetbrains.annotations.TestOnly
The first big difference is obviously that it's provided by different projects.
#VisibleForTesting is part of the Google Guava libraries and #TestOnly is part of JetBrains annotations which are associated with JetBrains, the makers of IntelliJ IDEA, among others.
Comparing the JavaDoc of the two shows that they serve basically identical goals: #TestOnly and #VisibleForTesting.
Note that the documentation of both annotations contain a note effectively warning you that the annotation itself does not prevent production code from calling the annotated method. JetBrains suggests the use of static checking tools that support that annotation (one of which is presumably built into IntelliJ IDEA) and Guava suggests the use of external checker tools with an explicit list of forbidden APIs.
tl;dr They indicate effectively the same thing. The decision which one to use depends mostly on which tools you are using to act on them and which one they support. Already using other annotations or classes from one of those packages is another reason to pick one over the other.
They are not for the same thing.
#VisibleForTesting is used for a methods that could be private/package-visible but has a higher visibility so it can be used by tests. Such a method can still be called in Production.
#TestOnly is used for a method that can only be used by tests, for instance to create a stub or to perform an additional validation only when testing. Such a method should never be called in Production, although the annotation won't prevent that.
By the way, JetBrains provide both annotations, so they can be used in the same project.
I am wondering whether it is possible with PowerMock or any other library to mock out a static call in a class from a library. The class in that third-party library makes a call to one of the classes in the rt.jar and I want a return a custom implementation of that returned Type. I am trying to do this outside of test code.
Otherwise, I had to extend a few classes from that library and replace some implementation. Has someone done anything like this before?
Yes it is possible, e.g. using PowerMock.mockStatic() or PowerMock.mockStaticPartial() if you want to mock one method, only.
There is a quite good tutorial on the homepage of PowerMock.
I posted an example on SO.
[EDIT] IF you want to do such magic in production code, however, I would recommend NOT to use a Testing-Framework. Maybe Groovy can help you with that - it is possible with Groovy to manipulate classes (even JDK classes) at runtime, and it is (I think) a thinner layer on top of the JVM.
Generally speaking it's really bad idea to do such hardcore stubbing (it's not mocking what you describe). I'd go with building tiny abstraction over this library so that you can have full control on what you want to return. It is possible to use some features of PowerMock outside tests but this not piece of cake. Here you have rough description that can help if you really want: https://groups.google.com/d/msg/powermock/SMDMe-y6fLg/1HF0TsGOqTIJ
Anyway I would not recommend doing that.
I have an application that is using Spring AOP with AspcetJ, and I want to convert it so that it can be used with spring auto proxy. Which means that I need to go through the code base looking for calls to #Transactional methods that are calling other #Transactional Methods within the same class and thus not going through the proxy, as well as #Transactional methods that are on private methods.
What tool or technique can I use to automatically find all the usages of #Transactional that would work with ApsectJ but not with auto prox?
Well, you are using AspectJ already, so why not use AspectJ to find out about such control flows dynamically and log them? So you could get rid of AspectJ by using AspectJ as an analysis tool. ;-)
I don't know of any tool that will find these out of the box. So you will probably need to write your own; but it is not trivial.
You can write an annotation processor to process methods/fields/classes with annotations on them. See the APT docs for how to write one and run it. (Note that in Java 6, apt is built into javac.)
However, finding out which methods call which other methods is quite difficult. Since you're talking about methods in the same class, it's a bit easier. You could use bytecode analysis for this (see this post for some relevant libraries): just parse out the invokevirtual and invokeinterface instructions in your class' methods, and see if they match the ones with #Transactional annotations on them.
Are there any Java runtime exploring tools? I mean the tools allowing to invoke concrete objects' methods in the running application (to check the correct behavior). It would be nice if I could substitute the object with another object of this type also, may be instantiated from sketch or deserialized from some source. As I looked, usual debuggers are limited in this possibilities, but I dont pretend to the fact Ive checked all of them.
I would suggest bytecode manipulation frameworks like ASM or BCEL for this purpose.
I would use basic jUnit and EasyMock for creating different input mock objects to check the behavior of your class in different situations. Then in the end you have a nice set of unit tests to maintain your codebase.
You should be able to achieve this at a higher level than direct bytecode manipulation using AOP tools such as AspectJ. Here are a couple of pointers:
http://www.ibm.com/developerworks/java/library/j-aspectj2/
http://danielroop.com/blog/2007/10/04/jmock-and-aspectj/
Protocol buffer classes are marked final, presumably for efficiency; however, this makes them quite difficult to test with -- Mockito can't mock/spy on final classes. I've tried using PowerMockito with no success: I get a ClassFormatError when preparing the final class for the test.
My solution up until now is to create mockable adapter interfaces, but I'm hoping there's a less laborious approach.
JMockit can handle final and static. Just pay attention to how to set it up as it requires the -javaagent JVM parameter, or classpath tweaks, or extra annotations to be able to mock final and static stuffs.
JDave has an Unfinalizer that integrates with the JMock ClassImposteriser
It can't unfinalize classes loaded from the the boot classloader, and it requires a VM argument when launching the tests.