Jonathan Blow – creator of two games that hold a very dear place in my heart, BRAID and THE WITNESS – posted a Twitter thread explaining why he doesn't like unit testing. I love reading informed opinions about software development, especially from folks who's body of work and experience are so different from my own.

This one went south quick though.

I would have loved to read a whole thread about how Blow, writing compilers and games and such, doesn't find a lot of value in unit testing. Instead, I got a diatribe about how dynamically-typed languages (like Ruby and Python) are awful, how unit testing as a practice can be replaced wholesale just by using a statically-typed language, and how folks writing software in dynamically-typed languages are unable to build anything of significant complexity.

Yeah. Let's unpack that.

Unit Testing as a Practice

It's very possible that the type of development Blow does doesn't lend itself well to unit testing. If that's true, he might have a dim view of that technique.

Speaking as someone who's professional body of work is in writing applications that encode an entire industry's worth of business logic, unit tests – both the actual bits of test code and the entire practice around testing – saved my ass more times than I can count.

I have never specifically written a unit test that could be completely replaced with a static type system.

It is 100% true that statically typed variables and a compilation step weed out many bugs that I encounter, but it's also true that my tests are not specifically designed to overcome my language's lack of either. It just so happens that running my tests will catch if I mistyped a variable name (same as running the compiler), and they'll catch if my float precision gets mangled becuase of a conversion somewhere.

The best tests I ever wrote were an executable version of my understanding of some business logic. These tests took all my experience, all my assumptions, and verifieid that the project met those requirements. The practice of writing those tests allowed me to communicate better with my teammates and with my customer. Because we practiced test-driven development, we were able to fix problems in our understanding of these business processes before we laid down the software to solve them.

Maybe some branches of the field wouldn't benefit from that, but we certianly did.

Tech Elitism at its Finest

A software developer from one branch of the field dismissing valid techniques from a disparate branch is not noteworthy. It happens so frequently that I doubt I'd have noticed if that was all Blow's thread turned out to be. But.

My dude goes on to completely shit on dynamically-typed languages and the developers who write software with them.

The better solution: use a language that doesn't have these problems, and you'll recover all that benefit, plus much much more. (It is worth pointing out that many of the people evangelizing unit tests for these purposes don't even realize that these things are non-problems in serious programming languages, which gives you a clue as to whether their advice is based on deep and thorough experience).


So unit testing is one of these techniques that doesn't pass the smell test. Whenever people are promoting it heavily, I can tell that they haven't shipped real-world, large, complex software [...]


I am a heavy proponent of unit testing your software where it makes sense.

I work in part of the industry where it makes sense so often that it's become a rule.

I have shipped software that automates and connects disparate ends of the American healthcare system, which absolutely matches the "real-world, large, complex" criterium. The team and I did it so well that the company got bought for over a billion dollars, which is a career milestone I'm unabashedly proud of.

All of my professional software has been written in interpreted languages with dynamically typed variables. Learning to write effective unit tests was key to helping me ship correct software fast.

Real work that holds entire corporations up is done every day in Excel, by folks who don't know to call themselves software developers and yet sit and solve the same kind of problems I do. It's done in SQL by folks with the title "data scientist." It's done in HTML and CSS. It's done in Javascript. And none of it is less worthy than the work I or anyone else does because of it.

I've done my fair share of ribbing folks for technology choices I disagree with, and maybe that was shitty of me then.

We're all in this together.

If this made you think thoughts, I wouldn't mind hearing them! I'm if email is your thing, beacuse federated protocols are cool, and I'm because lots of the folks I need to stay in touch with are still on Twitter. Always happy to talk with cool folks. Trans rights are human rights.

Post image by Kim Brooks via Flickr under the CC BY-NC-ND 2.0 license.