Rules for test driven bug fixing

Just a quick note to myself for how to do bug fixing:

1. Write an integration test that reproduces the bug
   This should create a test failure which will guard against regressions later on
2. Write integration tests for the other cases
   You should write at least one test. This should prove that it works the other way so you'll feel safe you don't break behavior later on
3. Track down the problem to unit level
   Debug to the lowest level where you can find the real cause of the problem
4. Write a unit test that reproduces the bug
   This should create a test failure which will guard against regressions later on
5. Write unit tests for the other cases
   You should write at least one test. There may be a chance that other corner cases have slipped as well, so examine closely. Keep in mind that unit tests are cheap!
6. Now, fix the bug
   Change it so all unit tests are green
7. Clean up
   Tidy up, don't leave a mess.
   Remember: Someone certainly will have to come back here. If that one is you, you will spend much more time, cursing the one who left that mess than if you do it right now!
8. Run the unit tests again
   Verify your clean up didn't break anything
9. Run the integration tests
   These should be green by now
10. Integrate changes
11. Create release

Reasons For Developing Without Tests

I've come to write this short article because I had some discussion with a developer about why he does not test. This discussion made me remember that many teams either don't do testing, neither on unit nor on integration level, or do it very sparsely. So I've come to write down a list of reasons that I've encountered and some questions that anyone hiding behind those reasons should have answers for.

Before you go right on to flaming against automated tests, please bear this in mind:

A script or program

• works in no more time than required
• when repeated does exactly the same

A human

• may be distracted
• interprets, thus may not follow the test script exactly
• takes shortcuts because he or she is bored of repetitive tasks

So here they are:

I don't have time for this

But you take the time for testing every change you make by hand each time, via the debugger or through the user interface? Or you don't and hope it will work? You want to continue doing a job manually that could be automated?
Don't you have some more important work to do?

I don't know the testing framework/tools

Learn them. The basic ramp up time for creating a unit test is very small. Every major IDE or build tool has support for testing.

Later on, when you start to integrate your tests into the build process, you will find out that Ant and maven both support JUnit out of the box.

I don't know if the boss will allow it

Ask him. Maybe he's glad that you asked and takes this as a sign of you taking responsibility for what you do.

I know the boss won't allow it

So you get paid to do a job that a script could also do, in less time and with fewer errors. Do you think he will like that when he discovers that?

I fear it will take too long

Try it in small steps. Consider that if you do nothing about it, it will take much longer in the long term.

I don't know where to start

Just start where you are, right now. The worst thing you can do is not do it, because it won't get better.

You will see, it's not as hard as you thought.

Are there any other reasons you know? Please provide them, I will see if I find an answer that convinces you.

Formatting curl xml result via xmllint

So I got fed up recently when reloading a url to check an xml result using chrome because I was using HTTP basic authentication also. Chrome was annoying me because each time i switched from no auth to auth I had to manually remove all browser data and restart chrome.

So I tried to use curl for that job. The only annoyance was that the xml is not formatted properly.

So xmllint for the rescue

curl 'yoururlhere' | xmllint --format -

and that's it.