Test-Driven Development is the practice of collaborating with all roles involved in a requirement and writing acceptance criteria for the behavior desired. It actually happens at all levels of Agile requirements but is best known at the product owner – development team boundary and with developers working with each other. The first is call Acceptance Test-Driven Development because we are looking for the acceptance criteria of the ask. At the team level, it is called Unit Test-Driven Development. There is some conofusion that TDD refers to Unit TDD but that is only because when TDD was first introduced with eXtreme Programming, it was being done primarily by developers.
The roadmap is a proven path for roll-out of technical skills in your organization. This roadmap provides a straightforward, effective path to follow which allows teams to focus on adopting one skill at a time and considers management concerns, like how long it will take for each investment to pay off. (Scott Bain. 5/2018)
A question that often arises in our consulting and training practices concerns the relationship between Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) and, what we might call Unit Test-Driven Development (UTDD).
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. (Scott Bain)