Related articles
Related reading pathsRelated topicsRelated resources
It is common for someone to say that TDD is “developers writing unit tests before the production code.” Yes, that is one form of TDD; but, it is a subset of a larger set of ideas and processes. It is also common for someone to say that ATDD is “acceptance tests being written before the development cycle begins.” Again, while this is correct it reinforces the idea that it is a thing separate from what the developers do when they are “doing TDD.” The reality is that they are all “Test-Driven Development.” They are not conducted in the same way nor are the done by the same people and the value they provide is different. But at the end of the day, TDD is the umbrella under which they fall. TDD is a software development paradigm. The whitepaper, Test-Driven Development: ATDD and UTDD by Scott Bain compares ATDD and UTDD, describing their differences (audience, creators, language, cadence and automation requirements) and their similarities. Here are a few of the similarities:
What TDD does not do, neither in terms of ATDD nor of UTDD, is replace traditional testing. The quality control/quality assurance process that has traditionally followed development is still needed as TDD will not test all aspects of the system, only those needed to create it. Usability, scalability, security, and so on still need to be ensured by traditional testing. What TDD does do is contribute some of the tests needed by QA, but certainly not all of them. In the paper, Scott concludes, So, the answer is that TDD and ATDD are not distinct from one another, but part of an overall approach to software development that places “a shared understanding of the behavior needed to achieve business value” first and foremost in the process, and that ensures alignment with the understanding in every activity that consumes resources. It also ensures that the knowledge possessed by the organization today will not be lost in the future. |