TDD is all about unit tests, which are written by the developers.
ATDD is all about acceptance tests, integration tests, bug regression tests, and system tests which are written by the testers.
BDD is all about software requirements described in a formal language, by the project owner or project manager, perhaps with the help of business analysts. The developers and testers are part of the collaboration & discussion, and the developers have to implement the nouns, verbs, and inquiries used by the BDD language (e.g., gherkin).
The big value of each is:
TDD: when the unit tests are written first, they help guide the developer write better code. Because the code will be unit test-able, which means it needs to be highly cohesive, and have no coupling, rely on no global state, and will be better designed. And for a very, very large system, the unit tests should run in a few seconds at most.
ATDD: automation of testing scales. The same tests can be run, repeatedly, and often. Likely will take hours, maybe days, to run the full suite of tests. Whereas, in comparison, manual testing does not scale - there's not enough testers in the world to test everything every time for every change for the entire system.
BDD: as the vocabulary of nouns, verbs, and inquiries grows, the PO/PM and BAs will be able to create novel behaviors because of the emergent expressive power. But moreso, the collaboration for shared understanding between the PO/PM, BAs, devs, and testers.
The way to ruin the value of each is:
TDD: write the tests after the code. At which time, then the tests are just being written for posterity as regression tests, and have lost 99% of the value of making them in the first place.
ATDD: have the developers write the tests. Because nothing hides a blind spot as much as having the person with the blind spot check for the things they can't see.
BDD: overloading the BDD system as a testers' platform for creating integration tests, bug regression tests, system tests, performance tests, security tests, et cetera. Or having the PO/PM abdicate responsibility for creating and owning the requirements in the formal language. Or by having the developers translate requirements from one system into the BDD language, and thus having to maintain two sets of requirements in two separate systems. Or by eliminating the meetings around BDD, which eliminates the key benefit to BDD.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I see the differences as...
TDD is all about unit tests, which are written by the developers.
ATDD is all about acceptance tests, integration tests, bug regression tests, and system tests which are written by the testers.
BDD is all about software requirements described in a formal language, by the project owner or project manager, perhaps with the help of business analysts. The developers and testers are part of the collaboration & discussion, and the developers have to implement the nouns, verbs, and inquiries used by the BDD language (e.g., gherkin).
The big value of each is:
TDD: when the unit tests are written first, they help guide the developer write better code. Because the code will be unit test-able, which means it needs to be highly cohesive, and have no coupling, rely on no global state, and will be better designed. And for a very, very large system, the unit tests should run in a few seconds at most.
ATDD: automation of testing scales. The same tests can be run, repeatedly, and often. Likely will take hours, maybe days, to run the full suite of tests. Whereas, in comparison, manual testing does not scale - there's not enough testers in the world to test everything every time for every change for the entire system.
BDD: as the vocabulary of nouns, verbs, and inquiries grows, the PO/PM and BAs will be able to create novel behaviors because of the emergent expressive power. But moreso, the collaboration for shared understanding between the PO/PM, BAs, devs, and testers.
The way to ruin the value of each is:
TDD: write the tests after the code. At which time, then the tests are just being written for posterity as regression tests, and have lost 99% of the value of making them in the first place.
ATDD: have the developers write the tests. Because nothing hides a blind spot as much as having the person with the blind spot check for the things they can't see.
BDD: overloading the BDD system as a testers' platform for creating integration tests, bug regression tests, system tests, performance tests, security tests, et cetera. Or having the PO/PM abdicate responsibility for creating and owning the requirements in the formal language. Or by having the developers translate requirements from one system into the BDD language, and thus having to maintain two sets of requirements in two separate systems. Or by eliminating the meetings around BDD, which eliminates the key benefit to BDD.