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.
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.
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.
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.
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.
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.
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.
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.
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.
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-source 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!
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 Java.
Nonetheless it’s an interesting question: does the choice of your programming language influence your programs’ quality?
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.
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 Infoworld.com).
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
NotImplementedYetException in an earlier article. Ceylon eliminates
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.
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!”