Category Archives: quality assurance

When Unit Tests Backfire

Everybody knows that unit tests are valuable. So it’s a lot of fun playing Devil’s advocate as I did some time ago when I raved about the value of compiler checks for keeping up the quality of your program. So here we go: unit tests are expensive. You never know when or if they pay off.

Thing is, my experience shows that unit tests are not always good. Sometimes they even backfire. I’ve seen this in at least two projects. This time, I don’t want to talk you out of using unit tests (maybe another day), but I want to make you aware of the risks.

Continue reading

About Owls, Nightingales and Clean Code

Sigh! Today I’ve been wading knee-deep through all-to-clean code. Code that might have been written in a textbook. Code following the style – yeah, once I was young and naive enough to believe the textbooks without asking – I taught at university. Code that follows all the best practices. Code following the rules of the Clean Code Initiative.

Code that’s illegible.


Yeah, illegible. I love clean code – but believe it or not, code that’s all too clean is every bit as illegible as spaghetti code.
Continue reading

Why Sometimes Unit Tests do More Harm than Good?

I always wondered how to write truly efficient and useful unit tests. So I’m glad my co-worker Thomas Papendieck offered to write a guest article, sharing his expertise with you. Thomas, it’s your stage!

Unit tests are cool!

Unit tests secure already existing behavior in the code base and support the programmer while doing changes by detecting damages.

Almost every programmer knows this statement.

…but are they really?

On the other hand almost every programmer made the opposite experience: Unit tests come in the way of the programmer when she wants to introduce changes to the production code. After the change a whole bunch of unit tests broke and it takes a big effort to make them pass or even compile again. I remember projects where fixing tests took up to ten times longer that the actual change.

Why does that happen? Is it that unit tests are only hyped by ivory-tower screwballs propagating academic ideals? Those lucky dreamers never being responsible for a real life application?

The staggering answer is: No.

Continue reading

Selenium Dreams

Last week I’ve blogged about Cucumber and Selenium. In the meantime, my enthusiasm has cooled down considerably. I ran into a host of problems. Browsers simply aren’t intended to be controlled remotely. Quite the contrary. A remote control for your browser is a hacker’s dream. As a consequence, browsers tend to resist the remote control. However, Cucumber and Selenium are still the best tools I know, so I continued to work with them, and by the look of it, they will continue to work with them next week.
Continue reading

Cucumber Meets Selenium – How to Make Testing Web Applications Fun

Do you know anybody who loves to test their code? I don’t. Granted, there are those guys raving about the test first approach, but I always wonder which drugs they take. Maybe I’ve found the answer. Maybe its a simple Cucumber.

No, I’m not talking about the green stuff some of you grow in your garden. (Don’t even try to smoke it!) I’m talking about a framework that makes testing a lot more fun. I use it together with another interesting test framework, Selenium, which in turn builds on WebDriver, which is a remote control for your browser. You end up with a series of commands in plain – if slightly stilted – English that test your web application in a real browser. How do you like this test case?

Given I am on the BootsFaces start page,
When I navigate to "Getting Started" / "PrimeFaces",
Then I can read that "BootsFaces plays nicely with PrimeFaces."

That’s not a high-level description of the test in a Word document. It’s executable code. Eerie, isn’t it?

Like so often in the world of programming, it stops being eerie once you’ve started to look behind the stages. Which is what we’ll do in this article.
Continue reading

How to Use Mockito to Test JSF Components

There are two strategies to write JUnit test for JSF applications. The first strategy uses a tool like Arquillian to start both an application server and a browser that runs a JSF application. Yeray Santana Borges used this strategy to contribute a couple of JUnit tests to BootsFaces.

This approach has many advantages. It runs on a real application server, and it runs on a browser that can execute Javascript. In other words, it’s a very close approximation of the real world. You can test a lot of things, including behavior and AJAX requests.

The big disadvantage is performance. It takes a while to start an application server. That’s bad if you want to run hundreds of JUnit tests on every build. Usually projects prefer to define a dedicated Maven profile to run this kind of tests. By default, the tests are skipped by the build. They are run only during a nightly build.
Continue reading

Getting Started With Continuous Delivery

Basically, Continuous Delivery is simply a clever idea to make software development more simple, more reliable and more efficient. Sounds like simply tweaking the development process here and there, doesn’t it? But when you’re an experienced developer starting with Continuous Delivery, you’ll be surprised to meet a whole bunch of new tools you’ve never heard of. I found this pretty confusing: CD is a development process, but when I asked how to employ CD in my company, all of sudden people started to talk about tools. Worse, you’ll even learn new vocabulary, and you’ll have to acquire a lot of knowledge that’s previously been the exclusive domain of your operations department.

On second thought, that’s not surprising: One of the key ideas of Continuous Delivery is to make developers and operations collaborate more closely (an idea commonly known as “devops”). Operations departments have always been using their own tools, and will continue to do so for good reasons, so developers have to make themselves familiar with the tools of the operations department. In particular, they have to get familiar to Unix shells, which is quite a chunk to swallow if you’re a visually oriented developer like me.

Adopting Continuous Delivery has at least three challenges:

  • The development process changes.
  • The cultural shift. Both developers and operations have to learn about each others job, and they have to do tasks they could previously delegate to “the other department”.
  • Your team has to install and use several tool they wouldn’t need without CD. Expect to invest in courses and trainings.

Use Exceptions. Use’em Wisely!

The other day I’ve been reviewing another department’s code. Soon I was puzzled by the way they use exceptions. They use them very often and in unexpected ways. I examined a very small module, just a handful of classes, and the vast majority of the classes were exceptions. After a while it crossed my mind they followed an old style that’s come out of fashion for a good reason.

So I decided to write an article on how to use exceptions efficiently. In a way, this is a strange article: it’s a basic topic (actually a topic already covered by many, many other writers), but it’s not the newbies who do it wrong. It’s the old hands who walk into the trap.
Continue reading

How to Write Your Own SonarQube Plug-In

You already know SonarQube, I suppose? If you don’t, don’t waste your precious reading this article. You’d rather have a look at their live demo first. Nemo shows the result of SonarQube’s analysis of quite a few popular open source projects.

But wait, I’d like to tell you what Sonar is about first. After that I’d like to tell you it’s possible to write your own Sonar plugin.

What’s it all about?

Sonar (which recently has been renamed to SonarQube) is an open-source1 tool to improve the quality of your code. In a nutshell, it’s a combination of three popular tools: Checkstyle, PMD and FindBugs. It’s a common user interface to the three tools, plus a great GUI on top. The GUI is where Sonar excels: Never before has it been so much fun to discover errors and faults in your program!
Continue reading

  1. There’s also a professional version. See

Does Your Programming Language Influence Software Quality?

This morning Heise published an article I found exciting at first glance. They claim Python has a superior software quality.

At second sight thing look a little different. According to the comments, the article contains a number of mistakes. Maybe even worse, it’s utterly misleading. The study they cite says Python is high-quality software. They don’t talk about programs written in Python. Python itself is written in C. The JVM version of Python is written in Java1.

Nonetheless it’s an interesting question: does the choice of your programming language influence your programs’ quality?
Continue reading

  1. Both language contain a major portion – rougly 50% – of code written in Python itself. Without having dug into the code base I suppose the low-level code has been written in C or Java, while the higher level code has been written in Python itself. That’s a common pattern with programming languages.

Why “Eclipse Generates it Automatically” is a Bad Answer

I want my code to be simple, short and concise. I hate silly boiler plate code. Code that doesn’t add business value is code I don’t want to see.

Welcome to the Java world. Well-educated Java classes – and beans in particular – consist almost entirely of boiler plate code. Sometimes it’s hard to spot the business code among all the boiler plate code.

The fascinating thing is virtually nobody actually sees this boiler plate code. Experienced Java programmers are experts in masking out getters, setters and the like. It’s almost like the code wasn’t there in the first place.

And whenever I complain about it, the answer typically is: “It generated by Eclipse, so what’s the matter?”.

But it does matter indeed.

Continue reading

Ceylon’s Approach To Eliminate NullPointerExceptions

Maybe you’ve already heard of Ceylon. Ceylon’s a language initiated by Gavin King, the creator of both Hibernate and Seam. Putting it in a nutshell, Ceylon is an attempt to create a better version of Java.

The Ceylon developer team has released an early preview version (milestone 5). Andrew C. Oliver considered it to be mature enough to have a first look at it (see his article at

A very nice feature of Ceylon is the approach to NullPointerExceptions. This kind of mistakes is a real plague of the Java world. Usually they are caused by programmers who forgot to implement the “nasty case”. This is why I baptized the NullPointerException a NotImplementedYetException in an earlier article. Ceylon eliminates NullPointerExceptions completely.
Continue reading

The JSF Code That’s Just a Bit Too Clever

One of the best ways to improve your programming skills is to read code written by others. Today I was puzzled by a program that did work – but I couldn’t find out why. As I found out, it’s a fairly clever piece of code, and I guess you can learn a lot by reading it. It demonstrates the importance of the separation of concerns principle, and it demonstrates why boredom is a virtue amongst programmers.
Continue reading

There is no accurate documentation of your code but your code itself

It’s a common misconception that every program needs documentation. Most people seem to be terribly scared by programs lacking documentation. Whenever I am asked where my documentation is, inevitably this question is followed by the next question: “What happens if you leave the company? Nobody´ll be able to figure out your code!”

That’s nonsense.
Continue reading