Earlier this year I had the unusual opportunity to work on a project with another developer (I’ll call him Dave – not his real name) in which each of us was free to choose our own method of application development.

This is certainly not an ideal situation. At first I considered following the client’s (Dave’s company) development methods just for consistency, but I ultimately decided to follow TDD for my portions of the project for several reasons:

I’ve just re-planted our VMWareFB OpenStep display driver to Github, and I’ve updated our existing web page accordingly. Precompiled, compressed configs are now available in the downloads section of the new Github project page.

Special thanks to Andreas Grabher and other folks over at www.nextcomputers.org for solving the chronic problem of running at resolutions higher than 1024×768. Andreas has provided an updated source tree and config file, so after 8 years we’re moving from 1.0.0 to 1.1.0.

It’s been almost 8 years since Bill Bereza first wrote this SVGA driver for our customers over at Valley City Linen and we’ve hardly tinkered with it since. Lots of people have found and used it over the years, and are still using it today. It’s a pleasant surprise that it continues to work reasonably well for people out there in NeXT land.

Now that the code is out where people can freely update and re-release it, I hope to pull in a few interested members of the NeXT/OpenStep community and let them take it from here. I know a few people have privately hacked or updated the driver to work better for their own installations; I’d love to have them fold those updates back into the public source.

(Thanks to Marissa Christy for the cool logo sketches!)

Occasionally we find ourselves working with customers who have an impressive amount of custom software running their businesses. In some cases the business depends on the software.

You may think that would be a great situation for us, and it is, if the customer can actually afford the true cost of that software. But in some cases the customer acquired that software too cheaply.

Either they had a smart intern, a low-paid moonlighter, or just a desperate contractor. In the end, the result is very similar. They find they have a very powerful, but very complex tool, which they rely on, but which they can't afford to maintain. It's like giving a used Porsche to a poor college student. Unless they're a mechanical whiz themselves, needed repairs and updates are not going to happen.

It is possible to continue along with this process very well, if the customer is technically skilled themselves, or if they can continue to find cheap help. But someday a major change will be needed that will require expert help, and they will find that they can't really afford the work they want or need.

This isn't always a bad thing. The customer might find out they don't need all the complicated features they have, or they might be able to limp along and grow their business to a point where they can afford the system they have and want.

In the end, this is just debt of a different sort.

In the last few weeks, customers and potential clients have asked me on several occasions how Test-Driven Development relates to legacy code (incidentally, one fitting definition for legacy code is code having no test suite).

As much as we all might like to throw out legacy code (especially when it’s craptacular) and “do it right”, that’s often an entirely impractical option or just a plain dumb thing to do. Reality is that there’s no magical formula or one-size-fits-all procedure for dealing with testing and legacy code. Each case is unique and requires a thoughtful, responsible approach. That said, I offer here guidelines toward tackling the challenge in a thoughtful, responsible way.

Last week I was creating a web form that generated a few emails upon submission. I was dropping my code into a client's existing site that was developed by a different company. The existing code had no tests and looked like it was being pushed right to production via Dreamweaver or something similar. It was also one of those PHP, MVC-all-in-the-View situations. Hey, it's all party though... right?

I decided to manually test the form because the scope was small, there was no professional way to deploy the entire site, and there was no suite of existing regression tests that could be run. I still needed a way to iterate quickly while conducting manual tests.

Greasemonkey saved the day! I was able to write a quick script that filled out the form with some baseline data. I could switch some of the data manually and check the results quickly. I was able to use the same script in production. The experience reminded me of writing automated Selenium or Celerity integration tests and prompted me to think more about utilizing Greasemonkey as a QA tool.

--UPDATE--

Kristofer commented that a brief example would be useful.

Using Firefox, I got the Greasemonkey add-on. Once installed, I browsed to the form I was developing and navigated the Firefox menu: Tools -> Greasemonky -> New User Script... Then I wrote the Javascript that would fill in the form. I added a listener for the window onload event and within the callback I accessed the dom and updated the form values. It looked similar to this:

1
2
3
4
5

window.addEventListener("load", function(event) {
  document.getElementById("name").value = "Name";
  document.getElementById("email_address").value = "test@example.com";
  document.getElementById("address1").value = "123 Cranberry";
}, false); 

I had to create HTML and Mouse Event objects to invoke click and change events on some of the form elements that had their own event handlers. The Greasemonkey user script manager window allowed me to associate the script with my development and production deployments.

This was some really simple stuff that proved to be very helpful.

We’re working on adding significant new functionality to a legacy system. The budget doesn’t support a complete re-write. None of the legacy code has tests. The application domain is automotive testing. The particular problem at hand is controlling a throttle actuator (a simple robot that activates the throttle of a car while it’s being tested.)

The challenge

Legacy C source, 1600 lines. Many authors, 15+ years old. Complex if/else logic blocks with multiple clauses in conditionals. Several global variables. Throttle commands sent out serial port. Shared memory global variables via CPP macro interface.

How to add functionality in a TDD fashion for moving the robot smoothly?