Did you had the problem your mock must act like a bean? And you could not create the object with the real implementation? And the interface was too large, so you would not create a innerclass for the test? I had this problem too. I solved it with the answer in mockito.
This is a small summarization what the differences are between the different variations creating mocks with mockito.
Per default, after creating a mock, every method will return null. Just create your mock with:
Sample sample = Mockito.mock(ISample.class);
I think, this is very useful and straight forward. (And based by mockito developers idea, to create very fast a mock for testing). Sometimes it is very difficult to determine an error which was produced through such a null value. For this case it is very practicable to tell mockito, returning SmartNullValues.
How to find a concurrency bug – this was the question I asked myself some time ago.
It is always very hard to find a concurrency bug. Mostly you have no idea when it happens or if it is really a concurrency issue or some nasty bit of code. If it is a concurrency issue the question is if the bug is in your code or in a supplied library? Will the problem happen only on multicore processors or on any machine? Besides the technical problem the customer is eager to get a solution and management… we’ll i guess you know the story.
I won’t be able to tell you everything there is to know about concurrency testing – but I’ll show you a way that worked for me in most cases.
A few days ago, we upgraded the jdk we use for development. After this some developers experienced a special problem with our eclipse while debugging. When they set a breakpoint, eclipse did not stop. After a try and error phase we found a working solution. The problem disappeared when we set the vm parameter -Xms (define initial size of heap) to a higher value for the jvm inside eclipse. In our case we set -Xms to -Xms256m. We still do not know why this solution works. But we thought we’ll let you know.
Lucene offers great full text search capabilities. It is based on an index, which is maintained by Lucene. With Luke, the Lucene Index Toolbox (http://www.getopt.org/luke/) you can analyze your index and let explain queries.
After startup, you have to select your index. For this example, I created a test index with one file. It’s content is “this is a lucene test”. I used the StandardAnalyzer, which uses the WhitespaceTokenizer and filters out all tokens less than 3 characters and stop words. This will result in an index of the terms “lucene” and “test”.
Ant offers some XML features like the xslt task, which transforms XML files into other files. But unfortunately, with Ant you can’t make simple XPath Queries on a specific XML file.
Luckily, there is a nice open source solution called XmlTask, which offers many possibilities to work with XML files.
Wrong use of the memory options can cause serious performance problems. To optimize the right memory size of the JVM or to find some critical memory issues, the GC log of the JVM can be very useful. Simply start the Java application with the option -Xloggc:<file>. Every GC action gets logged into this file.
To analyse this log file, there is a nice tool called GCViewer, which can be downloaded from http://www.tagtraum.com/gcviewer-download.html. GCViewer is able to display the memory usage of the application based on time and old/young generation heap space.
There are some kind of tasks, which Ant won’t do. One of them is the loop. There is no simple way to implement a dynamic for or while loop in Ant. What do i mean with dynamic? Let me make an example. Ant reads out a number of iterations from a property file (we call it the number x) and should perform a loop x-times to call another Ant task. And this can only hardly be done with Ant.
But fortunately, there is Groovy. Groovy is a scripting language, which runs in a Java Virtual Machine. And because of that, it can be easily integrated with Ant.
A few weeks ago, I started using Mockito. Mockito is a mocking framework for Java.
What mockito is able to do:
- mocking interfaces and abstract classes
- mocking concrete classes
- spy real objects
(http://code.google.com/p/mockito)
I liked mockito so much that I decided to present it to you…
Yesterday, I visited an interesting presentation from Tudor Girba. He showed us several ways for visualize code. One of the most interesting visualization was Code City.
(ArgoUML from http://moose.unibe.ch/tools/codecity)