There are some good reasons that test-driven development isn’t used as much as being discussed.
Everyone is talking about test-driven development. Does anyone actually do it?
For several years now, TDD has been embraced by the class of developers chatting in social media and technology conference panels as a “best practice” of agile development. But in a conversation with Diff blue CEO Mathew Lodge, former SVP of Python store Anaconda, I was beginning to wonder if all that chatter translates into action.
Diffblue uses AI to automate writing Java unit tests. In a Perfect World, Diffblue’s Cover, available for try for free, would be used to supplement TDD, but we don’t live in that perfect world. Let me explain why.
Theory and practice testing
TDD sounds great: in theory. In its purest form, developers write a test designed to fail first 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 if require new features.
TO SEE: Hiring Kit: Back-end Developer (Tech Republic Premium)
In the real world, no one writes a full and complete description of what the code is supposed to do, Lodge said. By definition, agile computing is all about iteration: incremental and frequent code improvements to achieve the desired result. In general, because nobody knows exactly how they want code to behave in advance, smart developers write tests before committing to continuous integration and continuous delivery pipelines such as CircleCI, GoCD, or Travis CI.
Plus, the developer doesn’t know what the API is for that thing 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. So how does the developer write tests first?
It’s no different from emerging AI code generation tools like Co-Pilot. People are surprised at first to see that it writes useful code, as if by magic. But when it comes to production, the best practitioners may get 30% of the code created by Co-Pilot, while the majority still needs to be written manually. Why? No one can fully and precisely describe in advance all the complicated software they want.
But in this case, that’s 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 time for developers is a good thing.
But again, talking to Lodge, it seems that TDD is failing 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.
TO SEE: Hiring Kit: Python Developer (Tech Republic 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 developer survey published in September 2020, it found that while 41% of respondents said their organizations have completely adopted TDD, only 8% said they write tests at least 80% of the time before code, which is the definition of TDD.
Given the choice of writing tests or code first, it seems that developers will almost always lean towards the latter, regardless of what the best practitioners say. Developers are nice people who like to argue and defend their own favorite goals, but ultimately the best developers are practical. They prefer to get things done. TDD isn’t dead, but it may not be as “alive” as we sometimes think.
Disclosure: I work for MongoDB, but the views expressed herein are mine.
