Huray!

My favourite plugin for IntelliJ IDEA TestDox finally works in EAP of version 8. So I can see nicely formatted test outline again. If I needed to wait longer I would be afraid that I could stop using pattern testShould... that I like so much :-)

For those who are not familiar with this approach it as as follows. Tests should describe what tested class should do. So it helps if test methods are named accordingly - describing expected behaviour. The best naming convention is testShouldDoSomething which should read as a sentence in English (of course name of tested class, or tested class in some context, makes begining of the sentence).

So for example let's have FullStackTest (specification) with method testShouldThrowExceptionAfterPush. This is time when TestDox cames into picture - it is able to convert it to Full stack should throw exception after push. Which feels really like specification of behaviour. And that's whole point. It seems subtle, but it works miracles. This plugin helps me to create good test names. It is even more important when I have lazy mood, because it motivates me to do so.

Its biggest disadvantage is that my Eclipse-based colleagues do not have anything like this (I tried to find it several times without any success, so if you know about something similar, tell me please).

Note: I have tried to update it to new IntelliJ IDEA API myself, but it was changed a lot and without any previous knowledge of IntelliJ plugin development and without complete list of changes I failed.

I mentioned readable tests yesterday and I have found following text in book Clean Code today.

What makes a clean test? Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code. What makes tests readable? The same thing that makes all code readable: clarity, simplicity, and density of expression. In a test you want to say a lot with as few expressions as possible.

It is nice to find confirmation of my beliefs in the book I like a lot.

Thinking about it I am not sure how I acquired this knowledge. Whether it was from some book or article or I just realized it after seeing a lot of bad tests (and writing them too). Indeed, it happened many times that I found much easier to understand production code and then I was not able to decipher tests to see how to modify them (or how to add new test). Or to find why test is failing.

Many times it seems that people care much less about the tests. It would be interesting to know whether they do not care or do not believe they are worth of effort or they just do not know how to do them better. I suspect the last possibility is culprit most of the times. Fortunately this is the easiest to fix. It just needs learning...

My colleague wanted to add comment to recent post, asking how it is possible to achieve good quality of code. Somehow it did not work as he did not see captcha code. Anyway, I owe him an answer (I hope it was not rhetorical question).

What to do?

In my opinion it is not very hard task. To achieve good internal quality of code (easy to modify and extend, no bugs, no environment for breeding new bugs) a few "simple" things must be in use:

Continuous learning

Without learning we cannot grow, but because our code base grows, new situations happen all the time and some of them cannot be handled by applying of old tricks (like for example "comments and Javadoc everywhere" that was useful in old days). If you look at your code written 5 years ago and you are satisfied with it, you are probably doing something wrong.

Writing readable and expressive code

If code is not readable it takes long time to understand what is going on. If we do not understand code we need to modify problems will occur sooner or later.

Continuous and merciless refactoring

Everybody should try to enhance any code they believe can be enhanced. Piece of code could be written nicely, delivering all expected behaviours in the beginning, but it will inevitably rot with time as new features are added, requirements are changed an so on. So it is important to counter attack it with refactoring.

Nobody should be blamed if piece of code looks strange and contains code smells after some time. But I believe that all developers should be blamed if they allowed it to happen without trying to fix it.

Continuous enhancement of existing code might look like daunting task, but it does not need to be. Any small enhancement every day will do (like renaming local variable or extraction of method). If all team members are doing it continuously they will be rewarded with great code base after some time.

Good tests - unit, integration, acceptance

With "good" I do not mean covering everything, but written in way they do not stand in way of future enhancements. They need to be simple, readable and modifiable. Otherwise they will become part of legacy code we wanted to avoid by introducing them.

Coverage is important too, but if you are afraid to look at test code because there is no way you could understand it quickly, you have bigger problem, that gets even bigger with time until tests stop serving their purpose and only prevent changes (enhancements) of production code.

It works for me

There are more approaches, like pair programming, code reviews, working reasonable hours and so on, but I wanted to mention those that are in grasp of everybody. I said they are simple. What I mean is that there is no magic or something unachievable in them. They only need dedication, persistence and enthusiasm.

There might be another virtue needed - courage. Courage to go against main stream of developers (and managers) that are afraid of changes ("If it ain't broken don't fix it" is their mantra). They are just paralysed by their fear. For example I have heard excuses like "But you don't know what class in other module could depend on this so you should not change public API." Well, it seems reasonable, but unfortunately it is good as excuse only. Many potential problems caused by refactoring will be caught by tests for module and all others by integration build. So if it really happened, that some unforeseen dependence failed to compile I will know soon enough. Compare that risk with its alternative - having that terrible code staying as is for next 2-3 years, causing unforeseen problems as other people will hack new features into it in the future. Does refactoring of code still look like bigger risk to you?

Uncle Bob talks about ethics of software professional, quality, readable code, reviews, code analysis and all other important things. I can only recommend to listen it to everybody. It contains serious stuff intermingled with jokes and I have enjoyed it a lot. http://elegantcode.com/2008/09/30/cast-cast-15-uncle-bob-martin/

I found following sentences regarding quality in Art of Agile Development while commuting to work this morning.

The best way I know to reduce the cost of writing software is to improve the internal quality of its code and design. I've never seen high quality on a well-managed project fail to repay its investment. It always reduces the cost of development in the short term as well as in the long term. On a successful XP project, there's an amazing feeling - the feeling of being absolutely safe to change absolutely anything without worry.

I wish more people were aware of this and acted accordingly. I have to make sure this happens at least at my present and future jobs.