I am experiencing an issue with mocking a static test with my code compiled with Java7.
I am annotating my jUnit test with the annotations
#RunWith(PowerMockRunner.class)
#PrepareForTest(StaticClassToMock.class)
When running my test and try to mock my static class with
PowerMockito.mockStatic(StaticClassToMock.class);
it returns
java.lang.VerifyError: JVMVRFY012 stack shape inconsistent [...]
If in StaticClassToMock I remove the Java7 constructs by substituting the catched exceptions in OR and putting them in cascade it works fine.
I saw that the last version of Powemock (1.6.6) is compiled with Java6.
Is my issue related to the Java7 constructs when PowerMock is compiled with Java6?
Thanks
That is the thing with PowerMock - welcome to its bizarre errors.
First question would be - are you using an IBM JDK? Because IBM JDK and PowerMock go even more "bizarre" than Oracle/OpenJDK and PowerMock.
If you do some search, there are plenty of potential hints around:
VerifyError on WAS
Code not working with Java7
Anyway, the first answer would be: simply try if running your JVM using -noverify makes any difference.
The longer answer: unless you are testing 3rd party code which you can't change; consider ... not using static code in a way that makes you turn to PowerMock.
You see, static is first of all an abnormality to good OO design. It should be used with great care; as it puts a lot of direct coupling into your code. And simply spoken: using static is a one of the simpl ways to create code that is hard/impossible to test! So, if changing your code is an option, you could watch those videos to learn how to create testable code in the first place. And then your need to turn to PowerMock ... will simply vanish.
My personal two cents: I have spent many hours hunting down such PowerMock problems. Then we decided to do different designs that only allows for static content that does not break our ordinary unit testing. Since then we are living fine with EasyMock and Mockito. No more need for PowerMock; no more need to spend hours on debugging problems that had nothing to do with our production code; but only the mocking framework.
Related
I've read this: http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html, and this: Should I use Groovy's #CompileStatic if I'm also using Java 7, and understand there are certainly performance improvements to be had but is that it? I don't understand exactly what #CompileStatic does.
Are there certain classes on which adding #CompileStatic is a no-brainer? Where would I not want it?
To cite my part of my answer to Should I use Groovy's #CompileStatic if I'm also using Java 7:
While faster than normal Groovy, it can compile only a subset of Groovy and behaves a bit different. Especially all the dynamic features are not available anymore.
All of the MOP will be bypassed. Builders won't work in general, some have extensions to the compiler to allow them passing though. Also methods are selected at compile time using static types, while Groovy normally uses the methods available at runtime and the runtime types. This can result in different methods being called.
Of course #CompileStatic also provides some security, since it is the tasks of a compiler to verify programs at runtime. But since static information is doomed to be incomplete, there can never be a 100% security.
So where is it a no-brainer... well... POGOs for example, since they don't usually contain all that much code. And of course for classes ported from Java to Groovy by copy&paste.
Where would I want it? Well, currently probably on Android, since there the code size has an impact and the static compiled code is more compact. Otherwise I personally am fine with not using #CompileStatic at all. This is more a matter of taste. In some cases there is a performance improvement for tight loops, but that requires you going and identifying by profiling your application first
Turns out that #CompileStatic can be useful when AOT compiling groovy programs - for example with GraalVM native-image tool. The native-image MethodHandle support is limited to cases where the MethodHandle object is a compile time constant. By using compiler configuration like:
import groovy.transform.CompileStatic
withConfig(configuration) {
ast(CompileStatic)
}
one can eliminate the dynamic MethodHandle instances in the generated bytecode and let the GraalVM ahead-of-time compilation succeed.
Is there any documentation for ServiceStack.Text.JSConfig with regard to MonoTouch AOT helpers?
I Found this...
ServiceStack JIT Error on MonoTouch
and I've had a look at the code but there are no comments and frankly it is a bit mysterious.
From my understanding of the AOT process all one needs to do to make sure a type/method is emitted is to have that type/method in one's source where the compiler thinks it may be used/called. It is not necessary to actually use/call anything at run time. The whole point of AOT is that it is a compile-time process. Consequently putting the use/call inside a method that is not used will work as long as the optimizer does not remove it.
I've been trying to use ServiceStack.Text.JsConfig.RegisterTypeForAot(); (in an unused method) to cure my AOT issues but have run into other weird issues when I have too many calls to it. See other question...
Calling ServiceStack.Text.JsConfig.RegisterTypeForAot<T>(); with MonoTouch causes SIGSEGV on startup on device
Could I maybe be using the RegisterTypeForAot() method wrongly?
What do the other methods do? RegisterForAot() and InitAot()
There is no documentation about JsConfig.InitForAot() other than what's already in-line in the JsConfig, i.e:
Provide hint to MonoTouch AOT compiler to pre-compile generic classes
for all your DTOs. Just needs to be called once in a static
constructor.
You should only have to call the JsConfig.InitForAot() stub and a JsConfig.RegisterTypeForAot<T>() for each type to let the MonoTouch compiler know what generic code needs to be pre-generated ahead of time so that all the code is available for generic reflection. If you run into a problem submit a small stand-alone test case with the issue on the GitHub project issues so we can see if there are any work around that can be done.
We have a couple of very very slow JUnit tests that make heavy use of mocking, including Mocking of static functions. Single Tests take 20-30 secs, the whole "mvn test" takes 25 minutes.
I want to analyze where the time is wasted but have little experience in profiling.
I assume that the initialization of the dependent mock-objects takes much too long.
Two questions:
1) How can I quickly get numbers in which methods the time is wasted? I need no complex power-user tool, just something basic to get the numbers. (evidence that the kind of mocking we do is evil)
2) Do you have ideas what design-flaws can produce such bad timings? We test JSF-backing beans that should call mocked services. Perhaps there might be some input-validation or not-refactored business logic in the backing beans, but that cannot be changed (pls dont comment on that ;-) )
ad 2) For example one test has about 30 (!) classes to be prepared for test with #PrepareForTest. This cannot be good, but I cannot explain why.
Here is my input on this:
Try using something simple like the Apache Commons StopWatch class. I find that this is an easy way to spot bottle necks in code, and usually when you find what the first bottlneck is then the rest of them are easier to spot. I almost never waste my time trying to configure an overly complicated profiling tool.
I think it is odd that you have such performance flaws in fully mocked unit tests. If I were to guess I would say that you are missing one or two mocked components and the database or external web services are actually being called without you knowing about it. Of course I may be wrong, because I don't use PowerMock and I make it a point to never mock any static methods. That is your biggest design flaw right now and the biggest hindrance to providing good test coverage on your code. So what to do? You have 2 options, you can refactor the static methods into class methods that can be more easily mocked. The other option is that you wrap the static methods in a class object wrapper, and then mock the wrapper instead. I typically do this if the static methods are from a third-party library where I do not have the source.
one test has about 30 (!) classes to be prepared for test with #PrepareForTest. This cannot be good, but I cannot explain why. This really sounds like you may also have methods that are doing entirely too much! That is just too many dependencies for a single method in about 99% of cases. More than likely this method can be seperated into seperate more easily testable methods.
Hope this helps.
First, I have to say that I really like Groovy and all the good stuff it is bringing to the Java dev world. But since I'm using it for more than little scripts, I have some concerns.
In this Groovy help page about dynamic vs static typing, there is this statement about the absence of compilation error/warning when you have typo in your code because it could be a call to a method added later at runtime:
It might be scary to do away with all of your static typing and
compile time checking at first. But many Groovy veterans will attest
that it makes the code cleaner, easier to refactor, and, well, more
dynamic.
I'm pretty agree with the 'more dynamic' part, but not with cleaner and easier to refactor:
For the other two statements I'm not sure: from my Groovy beginner perspective, this is resulting in less code, but in more difficult to read later and in more trouble to maintain (can not rely on the IDE anymore to find who is declaring a dynamic method and who is using one).
To clarify, I find that reading groovy code is very pleasant, I love the collection and closure (concise and expressive way of tackle complicated problem).
But I have a lot of trouble in these situations:
no more auto-completion inside 'builder' using Map (Of Map (of Map))
everywhere
confusing dynamic methods call (you don't know if it is a typo or a
dynamic name)
method extraction is more complicated inside closure (often resulting in code duplicate: 'it is only a small closure after all')
hard to guess closure parameters when you have to write one for a method of a subsystem
no more learning by browsing the code: you have to use text search instead
I can only saw some benefits with GORM, but in this case the dynamic method are wellknown and my IDE is aware of them (so it is more looking like a systematic code generation than dynamic method for me)
I would be very glad to learn from groovy veteran how they can attest of these benefits.
It does lead to different classes of bugs and processes. It also makes writing tests faster and more natural, helping to alleviate the bug issues.
Discovering where behavior is defined, and used, can be problematic. There isn't a great way around it, although IDEs are getting better at it over time.
Your code shouldn't be more difficult to read--mainline code should be easier to read. The dynamic behavior should disappear into the application, and be documented appropriately for developers that need to understand functionality at those levels.
Magic does make discovery more difficult. This implies that other means of documentation, particularly human-readable tests (think easyb, spock, etc.) and prose, become that much more important.
This is somewhat old, but i'd like to share my experience if someone comes looking for some thoughts on the topic:
Right now we are using eclipse 3.7 and groovy-eclipse 2.7 on a small team (3 developers) and since we don't have tests scripts, mostly of our groovy development we do by explicitly using types.
For example, when using service classes methods:
void validate(Product product) {
// groovy stuff
}
Box pack(List<Product> products) {
def box = new Box()
box.value = products.inject(0) { total, item ->
// some BigDecimal calculations =)
}
box
}
We usually fill out the type, which enable eclipse to autocomplete and, most important, allows us to refactor code, find usages, etc..
This blocks us from using metaprogramming, except for Categories which i found that are supported and is detected by groovy-eclipse.
Still, Groovy is pretty good and a LOT of our business logic is in groovy code.
We had two issues in production code when using groovy, and both cases were due bad manual testing.
We also have a lot of XML building and parsing, and we validate it before sending it to webservices and the likes.
There's a small script we use to connect to an internal system whose usage is very restricted (and not needed in other parts of the system). This code i developed using entirely dynamic typing, overriding methods using metaclass and all that stuff, but this is an exception.
I think groovy 2.0 (with groovy-eclipse coming along, of course) and it's #TypeChecked will be great for those of us that uses groovy as a "java++".
To me there are 2 types of refactoring:
IDE based refactoring (extract to method, rename method, introduce variable, etc.).
Manual refactoring. (moving a method to a different class, changing the return value of a method)
For IDE based refactoring I haven't found an IDE that does as good of a job with Groovy as it does with Java. For example in eclipse when you extract to method it looks for duplicate instances to refactor to call the method instead of having duplicated code. For Groovy, that doesn't seem to happen.
Manual refactoring is where I believe that you could see refactoring made easier. Without tests though I would agree that it is probably harder.
The statement at cleaner code is 100% accurate. I would venture a guess that good Java to good Groovy code is at least a 3:1 reduction in lines of code. Being a newbie at Groovy though I would strive to learn at least 1 new way to do something everyday. Something that greatly helped me improve my Groovy was to simply read the APIs. I feel that Collection, String, and List are probably the ones that have the most functionality and I used the most to help make my Groovy code actually Groovy.
http://groovy.codehaus.org/groovy-jdk/java/util/Collection.html
http://groovy.codehaus.org/groovy-jdk/java/lang/String.html
http://groovy.codehaus.org/groovy-jdk/java/util/List.html
Since you edited the question I'll edit my answer :)
One thing you can do is tell intellij about the dynamic methods on your objects: What does 'add dynamic method' do in Groovy/IntelliJ?. That might help a little bit.
Another trick that I use is to type my objects when doing the initial coding and remove the typing when I'm done. For example I can never seem to remember if it's .substring(..) or .subString(..) on a String. So if you type your object you get a little better code completion.
As for your other bullet points, I'd really need to look at some code to be able to give a better answer.
We're writing a large production system in Java, and I'm considering whether or not we can write some of the components in one of the JVM-based dynamic languages. Groovy appears to be the best choice from the Java interoperability standpoint. But is the Groovy implementation reliable enough to use in production (I would assume so), and is the Groovy language specification itself stable enough so that we aren't going to have to revise our production code substantially in a year or two? What are your experiences?
Summary (5/30/09): Good comments, the sense I get is that you should be cautious in adopting Groovy for mission-critical production use, it's fine for ancillary usages like putting together test cases, and there's a middle ground where it's probably fine but do your homework first. Performance is an issue, which needs to be balanced against the increase in developer productivity. Bill and Ichorus have equally helpful answers based on Groovy use, so it was a coin toss.
Update (12/3/09): More recently I've been taking a serious look at Scala, another JVM language. It was designed and implemented by Martin Odersky, the original author of the current javac compiler and the co-designer of Java Generics. Scala is a strongly typed, but uses type inferencing to strip out a lot of boilerplate. It's a nice blend of object-oriented and functional programming. James Gosling likes it. James Strachan, the author of Groovy, likes it too. And Odersky's experience writing javac means Scala's raw performance is not far from Java's, which is impressive.
Update (4/26/11): Take a look at Groovy++, a statically typed extension of Groovy, which has performance equivalent to Java. Looks very interesting.
Edit: Here almost four years later and Groovy has become much more solid.
I can wholeheartedly recommend it for production grade projects.
I've been using Groovy to support production applications for a while and for that purpose it is stable enough. As for actually having Groovy in bona fide production code; I don't think I would do that. Groovy does too many surprising things. It has gotten much better in this regard over the past year or so, but every once in awhile I will run into a bug that is a bit difficult to track down because of the generated code (my issues seem to have revolved around scoping).
I have gotten away from Groovy (though the stuff that we use that is simple and solid is still around) and have used Python (jython implementation), which has been far more predictable in my opinion. Also, python trumps Groovy in readability.
You can write some very interesting code in Groovy with closures and operator overloading and whatnot.
These languages are used for convenience and speed on ancillary code...stuff that can be switched out on the fly if need be. None of it is in production. I don't think I would put either in production unless it was as a stopgap to get something critical out of the door in a major hurry or as a proof of concept or prototype.
And in the case of putting it in actual production, it would have to be in the most dire of circumstances and I would assign someone to rewrite it in pure Java for the next release. I am 98% sure that either would be fine in production but that 2% is too much unnecessary risk.
We've got several production apps running on Grails (using Groovy as the language). So far, no issues have resulted. As for JVM compatibility, take a look at how little the JVM byte-code has changed in the last 5 years... like 1 instruction was added, and none were made obselete.
Will new versions of Groovy come out in the next year? Yes. Will you be required to change to them? No. Though you might want to, 1.6 is a huge speed improvement.
Which brings us to the major drawback of Groovy, the speed issue. Obviously, Groovy is slower than straight Java. The current number are up to 10 TIMES slower, for certain actions. That said, is your CPU the bottleneck in your app? For us, it's mostly DB access and latency. If it's the same for you, what matter if the CPU spends 200ms processing the page request instead of 35ms?
Is that the only problem with Groovy? Nope. Dynamic languages have refactoring difficulties, since there isn't necessarily a complete class specification anywhere in the code. However, this is partially balanced by the smaller code-size which makes it easier to find the places to modify the code.
Anyway, Groovy is a perfectly fine language for production uses. Mix it with Java for your "critical" code, if you fear the reliability. That's the BEST part of Groovy... how easy it mixes with Java classes.
I'm currently exploring using Groovy for only writing unit tests. This has the effects of
Allowing the potentially tedious part of writing tests to be done in a syntax that is a bit simpler than Java.
Keeps the Groovy code out of production.
Allows a large portion of the code base to be written in a non-Java language.
Of course, we haven't started yet, but this is at least my way of attempting to introduce alternate JVM languages to our new projects (and possibly existing ones). I have the same concerns you do, and even more so around performance than stability.
Scripting languages evolve "too fast" in the aspect of syntactic features.
If you want a language for the JVM that will stay compatible for
many years,
Java is your only choice ;)
By the way, I don't think that the readability of code is
ensured by a scripting language automatically.
We used Grails/Groovy as our primary backend at my previous company, and from that experience I'd say that I would choose Groovy over Java in most circumstances I am likely to encounter, since it interoperates with Java seamlessly and is otherwise more fun and expressive. Additionally I would expect the database would almost always be the bottleneck of my application rather than language performance, and we didn't encounter any stability issues/bugs with groovy as far as I recall.
But personally it's usually not about Groovy vs Java for me in most cases -- it's about Groovy/Java + available libraries vs. other languages like Python/Jython/JavaScript/Ruby + available libraries. And there are a lot of other considerations there such as strength of community, maturity of relevant technologies for your particular application, etc. In particular, for web development, Grails was decent, but the community seemed lacking. My overall opinion is that I would use python or Node.js going forward. If I needed the JVM I'd use a jython-compatible python web development environment.
I've been playing with Groovy for a month or so. The simplicity is awesome, and the dynamic language features are really cool too. However, speed is definitely an issue. Also, the groovy console really sucks. You cannot do things that you can do e.g. in python. Every once in a while I have to restart the console, reimport, things, etc. It also keeps forgetting the values I put in the variables while in the console mode; somehow mystically they go out of scope. (Is it because of the JVM? I don't know.) I cannot come up with an example from the top of my head, but the behavior I get in the Groovy console is different from the behavior I get in the Grails console, and is different from what I get by just writing code in a script.
A few more warnings. Note that Groovy is almost, but not 100% compatible with Java. For example, this will not compile:
public class HelloWorld {
public static void main(String args[]) {
System.out.println( "Hello, world!\n");
}
}
Also take a look at How to get classpath in Groovy?