Characterization tests provide a safety net for your legacy Java code by helping identify unintended changes in software behavior caused by code maintenance. JUnit Factory from Agitar Software may be used to automatically generate these tests for you. In this post, we’ll take a look at what happens to these characterization tests when a simple code change is made.
JUnit Factory is a free Eclipse plug-in from Agitar Software that generates characterization tests for your Java code. For more background on what characterization tests are, and how you use them, you’ll want read my post “Characterization Tests: How To Deal With Legacy Java Code”.
This article describes how to generate tests for a simple Java class and how to read the tests. Not all of your real code will be this simple, and not all generated tests will be this simple, either. But, bear with me as we start small and work our way up.
Companies have invested billions of dollars over the last decade building components and applications based on the Java framework. This work represents a wealth of expertise and collective knowledge that firms must protect and maintain. Unfortunately, in the dynamic field of software development where programmers change jobs, on average, every 18 months, the original developers on these past projects probably aren’t around anymore.
As a result, Java developers seldom have the luxury of working on true greenfield projects. Instead, they are faced with adding enhancements and fixing bugs on projects built upon a code base they didn’t write and don’t fully understand. How can developers safely make changes to legacy code without accidentally breaking something unrelated?
Characterization tests provide a safety net – a change detection engine – that identifies behavioral changes in legacy code in order to remedy regressions early in the development process. Fixing regressions early shortens development timelines, increases code quality, and allows a team to become more agile. You can automatically generate your team’s characterization tests using the free JUnit Factory for Java from Agitar Software.
Uh, oh. I think I’m way too young to sound like such a curmudgeon, but I just can’t help myself. Before my recent move to a post-sales role, I spent 15 years writing software professionally. I thought at this point in my career I’d qualify as “the wise elder” – instead, I guess I’m just “the crazy old man who mumbles to himself.”
Remember the days of eagerly poring over core dumps to quash that nasty bug? The fascination of learning something new? The determination to write code properly so it could be maintained and easily understood by others? Remember when “so what? it works” just wouldn’t cut it for maintainable design?
I loved it. So, what is it with kids these days?
Vincenty’s Formula is an iterative solution for calculating the distance and direction between two points along the surface of Earth. For clarity, I’ve stripped out portions of the code I’ve put up for discussion, but you can download the entire Java source code from here. If you prefer C#, please see the C# version of this discussion.
Several years ago, I stumbled on a great pastime called “geocaching.” It’s a worldwide treasure hunting game where participants use handheld GPS receivers to find hidden “caches” – small boxes filled with prizes, trinkets, and “travel bugs“. The caches are hidden by other participants who post nothing more than the latitude and longitude on a website like Geocaching.com. My children and I have had a blast. It’s a great way for a grown man to justify playing in the woods (and buying an expensive gadget!) under the pretense of “playing with the kids.” With over 420,000 caches in 222 countries on all continents (including Antarctica!) there are bound to be several near you.
Roundoff problems have been the bane of programmers since computers started handling floating point numbers. Floating point numbers are represented by a finite number of bytes. This limits the precision of numbers that may be represented – you only get so many significant digits. More subtly, however, finite length floating point numbers limit which numbers may be represented accurately. Repeating decimals (which, in a sense, require an infinite number of significant digits) cannot be represented precisely. You may only store the nearest value representable by the computer. This is the origin of annoying roundoff problems found in floating point arithmetic.
The C# and Java 4-byte
float data type provides 7 significant digits of precision, while the 8-byte
double type provides 15. Using the higher precision
double data type helps minimize the roundoff error, but it must still be addressed.
So, when I encountered the C# 12-byte
decimal data type with its 28 significant digits, and Java’s arbitrary size
BigDecimal data type, I figured these were simply ways of further minimizing the problem with a wider floating point type. Only after digging deeper did I realize that the implementation behind both of these data types is a stroke of genius.
I have to admit, when I first heard about the open source project Crap4j, I thought it was a joke. It sounded like a sarcastic, tongue-in-check spoof on the masses of brittle legacy Java code accumulating daily in software development shops around the world.
It isn’t a joke.
The Crap4j Web site describes the Change Risk Analysis and Predictions software metric as “a mildly offensive metric name to help protect you from truly offensive code.” Well said. The levity of the name belies the seriousness of the problem. Java is no longer a new language. Greenfield development has made way for maintenance and incremental upgrades to massive legacy code bases for which the original development team is long gone.
We all know legacy Java code is often poorly documented, but dig a little deeper and you’ll discover something even worse: it’s poorly tested! Now, consider that legions of developers have added little tweaks and bug fixes along the way without giving consideration to meaningful refactoring. What else can you do but throw up your hands (or your lunch) and declare “This code is crap!”
I’ve recently started experimenting with NHibernate – the C#/.NET version of the Hibernate O/R matpping tool that was originally developed for Java. The Java version is very powerful, and I’m a huge fan of it. The C#/.NET version is, for the most part, a straight port of the Java code base (and an ugly port, in some ways). Nevertheless, it appears to be just as robust as its predecessor.
Be warned, however, that the NHibernate DLLs require a high level of trust in the ASP.NET environment they’re deployed to. I spent an entire weekend beating my head against a wall trying to get a simple app up on my GoDaddy account. I suspect NHibernate probably wasn’t designed with a medium trust environment in mind. I was able to make a few tweaks to get the code running with fewer permissions requirements. However, the permissions required to enable dynamic proxies – a fundamental part of the NHibernate architecture – are non-negotiable.
I learned from GoDaddy tech support that their Deluxe Windows plan, a shared host environment, simply doesn’t allow those permissions. I’d need to upgrade to a dedicated server, and that’s just a little too pricey for an environment simply for experimentation. I was able to get NHibernate working without any hacks at Webhost4life, but I thought I’d share what I tried first at GoDaddy just to help you understand the permissions implications if you’re in a medium trust environment — and how you might need to address them on your own projects.