Referencing a Bean in JasperReports

Thanks to this answer on StackOverflow, I know how easy it is to reference the bean itself instead of one of its properties in a text field expression in JasperReports. The trick is to declare a field whose description is set to the keyword _THIS:

Then it can be referenced in the text field expression as follows:

Regex for German Zip Codes

I found the following regular expression (source) working fine for me:

I tried two alternatives that did not work because they were too general:

The first regex matches the zip code “00000” which is invalid in the German system. The second regex matches the zip code “99999” which is invalid, too.

Testing Delegate Methods

We had an interesting discussion the other day: should we write unit tests for delegate methods, that is, methods that only delegate the call to a delegate object? Here’s an example of such a method:

I said I did not see much value in a unit test for this method as all the test could do is verify whether the do()  method of the mocked delegate object was called. Instead of testing behaviour, we would test the wiring which is close to trivial in this case and should be tested implicitly as part of an integration test involving the delegate object and the main object.

Some of my colleagues disagreed with me. Their argument was that a unit test would detect changes in the delegate call and indicate the intended usage of the delegate object. They were concerned an incorrect wiring could be introduced without a unit test. And this unit test would be cheap to write.

I did not find any of these arguments very convincing – and I’m in good company: the JUnit team’s FAQ webpage has a section on Best Practices which comments on testing delegate methods. You can read it here. Thank you, J. B. Rainsberger!

How to Make Unit Tests more Likeable

What are these unit tests good for? Are we testing Mockito?

This is what a colleague asked another colleague a couple of days ago. He was referring to some rather complicated and long unit tests that used a lot of mocks and verify statements. I knew what he was talking about since I had seen quite a few tests like that myself.

Whenever a JUnit test method has more than ten lines or so, I get suspicious (and sometimes start crying). Add a few ArgumentCaptors and I’m done with that test. If I’m supposed to fix a test like that, I tend to give up quickly and rather delete the test method than try to understand what is being tested and why it fails.

A good test, however, makes me smile. It’s short, concise and readable because it follows the arrange, act, assert principle. It uses Mockito’s fluent API if it uses Mockito at all. That’s anyString()  instead of Mockito.anyString()  and times(2)  instead of VerificationModeFactory.times(2) (which is Mockito’s internal API btw). And mocks, stubs, spies, and dummy objects are set up in the @Before  method instead of every test method. This saves a lot of boilerplate code and makes me want to fix the test if it breaks.