Untested code is broken code

The other day, I sat in on a demo Jesse St. Laurent was giving. The customer had a question about whether a feature worked in a specific scenario. Since it turns out that I wrote the feature, Jesse decided to defer to me. My answer was something to the effect of, “I’m 99% certain it works, but we’ll need to test it to be sure.”  That’s when Jesse told the customer a little about me, “Mike loves tests, and he believes if you haven’t proven something works with a test, then it doesn’t work.”

I graduated from college around the time when Kent Beck and Eric Gamma published a paper titled “Test Infected: Programmers Love Writing Tests”. This paper quite literally changed my life; I became ‘infected’. When the dot com bubble burst, I found myself working in a new field and was writing navigation software for helicopters. The gravity of my work was not lost on me; if I did my job wrong and someone flew a Medivac to the wrong place, then people could die.  After three years there and having returned to working for startup companies where I felt I belonged most, these lessons still stuck with me. A decade after I first read “Test Infected”, and started working with two of our founders, Jim King and Mike Healey, I knew I had found like-minded, highly talented engineers who also embraced the test everything culture. Jim went so far as to update our engineering job descriptions to include, “and if you believe untested code is broken code, we want to talk to you!”

At Tuono, we take your infrastructure seriously. That’s why we stick to high standards of unit test coverage. Our core engine sits at just under 98% covered—which means that we have a repeatable test that verifies correctness for that portion of the code. And it keeps getting better—one month ago, we were just under 97% covered.

On the above chart, green is equal to good so what does the big spot of red mean? The red area represents a small hole we have. Having this data means we are now able to assess risk and determine when to double back and fix that testing gap.

While unit tests are fantastic, we don’t stop there. Every time we publish new software, we run a battery of test deployments against the cloud venues we support to prove we still work in a live setting as expected. These tests take up to an hour to run, but after they’re done, we can be confident we have no regressions in our software.

And just in case that isn’t enough, we discussed the recent trend of having no dedicated Quality Assurance Engineers. Our initial thought process went something like this, “hey, we’re all ‘test infected’, we write unit tests, we have qualification tests, we know the code better than anyone else, why have someone else test it?”

But here’s the thing—the best QA engineers we knew challenged our assumptions about our own work, found problems we never dreamed of, and made us better. So, we are bucking the no dedicated Quality Assurance Engineers trend and building a world class QA team comprised of the best we’ve ever met.Oh, and that feature the customer asked about during the demo? While Jesse finished his demo, I ran a quick manual test to make sure it worked. On my to-do list this morning is writing an automated test to prove it. Now I know what the customer wanted to do will work and if I break it, a test will break. That’s just how we do things at Tuono.

Deploy your first environment