I was introduced to the concept of Test-Driven Development in 2012 by Steven R. Baker. I really, really didn’t get it. He was a passionate voice in the local developer community, while I was/am a rural guy, self-taught in programming and very accustomed to being the only one in the room who likes to make computer programs as a hobby.
We clashed big time, not fierce but sharp. Would it have been collaboration instead of confliction, the past six years could have been more spending-money and less priceless-life-experience for at least this one of us, to be sure. Six years later and I’m uncomfortable when I think about it. I haven’t been to a single meeting of those local developers in all this time. I’m not sure if I will ever get there.
I paid for training in TDD from J. B. Rainsberger. It was altogether too little time on the topic, so he should take no credit for any success of mine nor any blame for my foolish hackery. Sometimes you need to do whatever it takes to make the pleasant acquantaince of people you want to learn from and reason with.
It was just in and around this time that I started the Universal Enigma Machine Simulator project, using a TDD approach. I firstly wrote a failing test, then the code to make it pass. As the software grew in complexity approaching that of the machine under simulation itself, I refactored the code I had written earlier to make it easier on the eyes and mind. These changes were validated each time I reran the suite of tests and I continued along in this way with great ease and little worry until the project was completed.
I may not have taught myself TDD -it’s debatable- but I certainly developed the discipline to practice something like what I think TDD is meant to be, successfully. I’m quite proud of this!
A few years later and I applied TDD to my mf2 for PHP project. mf2 is an extension, written in C, for PHP, which provides a parser for consuming the microformats embedded in HTML documents. I have another little thing to do there before I get into the next phase, where the tests will pay some dividends as I refactor for performance.
Today I read about the Ada programming language via hackernews. It’s about the same age as I am and is more-or-less the official programming language of the U.S. Department of Defense. You may imagine as I do that it requires a great deal of discipline to write the programs driving the fly-by-wire electronics in modern stealth fighter aircraft, in satellites, in nuclear reactors, etc. I am admittedly surprised I have been at it this long without knowing this origination story of Ada.
I soon found myself doing background study on the Ada build tools and libraries. Then, searches for any articles on practical TDD with Ada. I found one mention to AUnit, with a link that went to a YouTube channel of non-test related tutorials. That wasn’t much use.
This was the first interruption in the study and the first time I went back in the searching I was doing. I realized I have yet to see the actual Ada code itself. The syntax is not nearly the most important thing I need to consider in evaluating the language and its accoutrements.
There it is! It’s six years gone and I am considering the tests, first. Okay, first-ish.