Chaotic Java

Unit testing is cruicial. If there is Anything you can say about the tools you need in order to create a framework, is that creating unit tests is your safety net when you decide to refactor it completely (and any framework, at its first steps, might go through such a thing – Nothing is ever fully designed for a future feature, not even a complete product.)

A few weeks ago I decided to have a major change to the way X2J analysation works, and use moulds and visitors instead of the previous, “everything-in-one-method” way. This change has worked great for me, but it was scary: What if X2J stopped working?

Sure, I could rollback the code – But that would serve to no good as I still needed this type of change. So I started writing tests. They weren’t JUnit tests, but just regular applications running X2J for me to manually check the results with. It worked, as amateur as it was, and I made the switch.

However, today I face another refactoring of code and I know I can’t do the same thing over again. I need some stability to my code. Some red lights to appear when I do something that risked a totally different part of my application. Something that will tell me almost precisely where I broke the code.

This is where JUnits come in, and if you haven’t been using them, you should do so now. I’m going to start creating them, starting this week. Only then will I tend to my refactoring tasks.