Test-driven development may be more talked about than practiced

There are some good reasons that test-driven development isn’t as widely used as it is discussed.

Everyone is talking about test-driven development. Is anyone actually doing it?

TDD has been embraced by the developer-chattering class in social media and technology conference panels for several years now as a “best practice” of agile development. But in a conversation with Diffblue CEO Mathew Lodge, former SVP of Python shop Anaconda, I started to wonder whether all that chatter is translating into action.

Diffblue uses AI to automate writing Java unit tests. In a perfect world, Diffblue’s Cover, available to try for free, would be used to complement TDD, but we don’t live in that perfect world. Let me explain why.

Testing theory and practice

TDD sounds great: In theory. In its purest form, developers write a test first designed to fail and then write the code. The idea is that the tests are the expression of what the code should do, then you write the code to pass the tests.

This will usually be an iterative process, starting with minimal requirements, writing tests, writing code, and then gradually expanding and refining the requirements in the tests and the code in small steps — refactoring code  as new failure modes are discovered or as new features require.

SEE: Hiring kit: Back-end Developer (TechRepublic Premium)

In the real world, nobody writes a full and complete description of what the code should do, Lodge said. By definition, agile computing is all about iteration — incremental and frequent code improvements to achieve a desired outcome. Because, generally speaking, no one knows exactly how they want code to behave in advance, shrewd developers write tests before committing to continuous integration and continuous delivery pipelines like CircleCI, GoCD or Travis CI.

Moreover, the developer doesn’t know what the API for that thing is because they haven’t written it yet. The implementation informs the API, and every developer knows how very difficult it is to get the API right the first time anyway. So how does the developer write tests first?

It’s not unlike emerging AI code generation tools like Co-Pilot. People at first are astonished to see it write usable code, as if magically. But when it comes to production, the best practitioners might get 30% of the code created by Co-Pilot while the majority must still be written manually. Why? No one can completely and precisely describe any complicated software they want in advance.

But in this case, that is an improvement for developers, and a substantial one. Just because Co-Pilot can’t generate 100% of the final code doesn’t mean it failed. It’s progress: Anything that frees up more developer time is a good thing.

But again, talking to Lodge, it seems that TDD fails this basic test. For greenfield code, it can sometimes make sense. But it’s so hard to embrace as a universal best practice in real production environments.

SEE: Hiring kit: Python developer (TechRepublic Premium)

Diffblue discovered this dirty little secret in an unrelated survey of enterprise developers in 2020, Lodge said.

Although TDD is popular, few shops practice it: A survey of developers published in September 2020 found that although 41% of the respondents said their organizations have fully adopted TDD, only 8% said they write tests before code at least 80% of the time, which is the definition of TDD.

Given a choice of writing tests or code first, it seems developers are almost always going to lean toward the latter, no matter what the best practitioners say. Developers are lovely people who like to argue and champion their own favorite causes, but in the end, the best developers are practical. They prefer to get stuff done. TDD isn’t dead, but it’s perhaps not as “living” as we sometimes think.

Disclosure: I work for MongoDB but the views expressed herein are mine.