Needs Revising[edit]

I submit that the main definition of this article should be revised. At its most base meaning, Acceptance Test Driven Development is the process of driving the software design and implementation effort of a software product by a set of Acceptance Tests which specify the behavior of the system from a end user's perspective (as opposed to specifying the behavior of the system's constituent parts). That is to say, A-TDD IS NOT defined by its participants or their level of collaboration, but by its methodology.

A-TDD is the process of first creating a set of specifications for how the system will be used by a user and then proceeding to write the code to make the specification pass ... optionally using TDD as an inner feedback loop for driving the low-level design of the system's constituent parts. A single developer can practice A-TDD in the development of a software package for which they have yet identified a customer. Likewise a small team of developers working directly with a customer without the aid of a Product Owner or QA Engineers can practice A-TDD by first establishing the user-level specifications and then developing the application to meet the specifications. To be very clear, this is not to say that the collaboration of users, product owners, QA engineers, and developers working together to create the set of specifications is somehow opposed to the A-TDD process, but only that collaboration of specific roles within the effort isn't a part of what comprises A-TDD.

One of the best books I've read on the topic of A-TDD is a "Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. It's been a few years since I've read the book, but I don't recall there being any focus on collaboration or any mention of roles (other than perhaps input from the Customer) in authoring the specifications. Can collaboration be an important factor in producing the specifications? Absolutely, but while collaboration may yield better quality acceptance criteria, this is orthogonal to the actual A-TDD methodology.

We don't want people to come away from this article mistakenly thinking that A-TDD prescribes some specific roles or types of interaction between Product Owners, QA Engineers, and Software Engineers as this may take many forms. It isn't about the collaboration that may or may not be happening, it's about the level at which the specification is written which drives the Test-First development process. Let's not confuse readers with something that sounds more like a prescription for social interaction. Derekgreer (talk) 23:03, 10 March 2016 (UTC)[reply]

Additionally, several other sections of this article are in need of rewrite. Under Testing Strategy, it talks about the process as if the customer writes the acceptance tests (though it doesn't say this specifically), that an "architect" writes component tests, and that developers write unit tests. This reflects 1980's thinking on software development methodology. First, there are no architects in software development. Another way to say this is that every developer is an architect. No one is painting by numbers, we are all designing software. The TDD process is all about emergent design. There are no architects handing down designs to the low-level developers in agile development shops. Such role distinction has no place in an article associated with TDD practices.

Also, the example section should show multiple styles of acceptance tests. I don't know that anyone can say "Acceptance tests usually follow such and such a form". Are there more Fitnesse tests out there Robot Framework tests? Are there more Gherkin tests than context specification tests? I don't really know, but unless you have some statistics to back up claims, it makes for a better article to demonstrate various styles and link to various frameworks that can facilitate A-TDD. These would include Fitnesse, Cucumber/SpecFlow, Rspec/Mspec as representative of the three different styles: table Wiki input style, BDD:Plain-Text Stories, and BDD:Context/Specification.Derekgreer (talk) 23:34, 10 March 2016 (UTC)[reply]

Unit tests derived from unit tests??[edit]

"Unit tests are created [...] They are often derived from [...] unit tests." -- this can't be right. Please correct it if you know the intended meaning (I don't). -- 194.39.218.10 (talk) 12:45, 7 October 2019 (UTC)[reply]

"Acceptance tests are a part of an overall testing strategy. They are the customer tests that demonstrate the business intent of a system. Component tests are technical acceptance tests developed by an architect that specify the behavior of large modules. Unit tests are created by the developer to drive easy-to-maintain code. They are often derived from acceptance tests and unit tests." So what we're discussing is acceptance tests, not unit tests. Walter Görlitz (talk) 19:22, 8 October 2019 (UTC)[reply]