This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: I'm in code debt
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
I'm currently in a bit of code debt. For those of you who don't know what code debt is, it is basically some smelly code and when you come to fix it, instead of refactoring it properly you instead slip in a dirty hack. This generates code debt because instead of fixing the problems you have squashed in a change which basically puts off the refactoring until the next time someone has put in a fix or extend the code. This is quite a good way to explain to boss/management types why you need to refactor code because slipping in a dirty fix is a bit like spending money on your credit card, you are just building up the debt but one day you will have to pay it back (fix the code)
Why am I banging on about code debt, well the reason I am talking about it is because of the state of my unit tests. The actual tests work and I have certainly felt the benefits of them and have more confidence in the code they are testing, not to mention the excitement of seeing the green bar pop up after a successful test.
The Junit tests are pretty smelly with quite a bit of duplication etc. I put some of this down to me being fairly new to writing Junit tests but also I wasn't sure whether you need to keep the code in junit tests neat and tidy, well to an extent. By the nature of junit tests they are sort of repetitious because they keep testing similar code. So in a few cases I have copied the majority of one test into another and modified it.
That was on my first batch of junit tests. I have modified my approach and now create variables like
result expected result testStringValue testIntValue
and use this same variables in all the tests but wiping them in the tear down and reassigning them in each test. I have decided not to go back and change the previous smelly code junits and modify them only if I am modifying the class or don't pass. I'm not sure how far to go when creating junits, how much code to put in them and should they be to the same standards as the code they are testing.
I have had a brief look but haven't found many articles on coding standards or best practices for junits. I think if I keep persevering I should start to create some kind of standards and I think I need to work on improving them. The only nagging thought is that when you are writing junits they don't need to be of the same quality as standard code because you are unlikely to extend them or debug them. I suppose I will have to pay this code debt when I have to change the class and then change the junits.
I would be interested to hear comments of people who write junits and their approach.
Previous Topic
