ATDD in Practice
Acceptance Test Driven Development in practice

Table-based frameworks
FIT, http://fit.c2.com
FitNesse, http://fitnesse.org/
Concordion, http://www.concordion.org/

https://wiki.jenkins-ci.org/display/JENKINS/Concordion+Presenter+Plugin

canoo webtest

RobotFramework, http://robotframework.org

Text-based frameworks
Exactor, http://exactor.sourceforge.net
TestTest, http://texttest.carmen.se

Selenium
Watir/Firewatir

Database

http://www.dbunit.org/

dbunit

http://jailer.sourceforge.net/

database subsetting

Cucumber, http://cukes.info/ http://cuke4ninja.com/
Celerity, http://celerity.rubyforge.org/
Capybara
WATIR /WATIN, Cucumber
WATIN

sikuli http://sikuli.org/

http://www.docin.com/p-68882088.html
watintestrecord.sourceforge.net/

http://qa.taobao.com/?p=11763

http://qa.taobao.com/?p=11755

https://github.com/MarkusGaertner/Triangle-Test-Sampler

BDD: ATDD done well?

A new form of an old question has been asked in the Behavior Driven Development community: is BDD merely Acceptance Test Driven Development done well? While the community calls out the differences, Dan North makes a request to avoid focusing on them, calling TDD "amazing".

When Dan first introduced Behavior Driven Development, he changed the language commonly used in TDD, using the vocabulary of examples of behavior in place of tests. Some members of the Agile community suggested that BDD was merely "TDD done well". Now, tools like Cucumber, JBehave and SpecFlow have matured to support BDD's scenarios in which we describe the behaviour of an entire system or application from a user's perspective, bringing the language of "Given, When, Then" to the Acceptance Test Driven Development space. The boundaries of BDD are still unclear, and the community are revisiting the old question and asking, "What makes BDD different?"

In his talk, "How to Sell BDD to the Business", Dan produces, then unpacks, this definition of BDD, showing how it applies to many different phases and scales of software development:

"BDD is a 2nd generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, Agile methodology."

Dan also promises to define BDD more clearly at a later date. Wes Williams, author of the GivWenZen framework, responds:

"I think this definition leaves out a key piece, we are focusing on collaboration and learning. Having worked on a project that was using 'ATDD', in 2005 I think, we had the same goals then as BDD without the Given When Then language."

In his original introduction to BDD, it was the use of language at a low level which prompted Dan to change "test" for "should". Neel Lakshminarayan picks up on this:

"BDD is also a lot about using the "right words" - an important differentiator. That’s very subtle, but very powerful ... Very different questions start popping into your head. Instead of "What should I test?" , you might hear "What’s the intended behavior?". This will cause you to think differently and therefore, you will write very different code."

So what is the difference? As well as using different language, Dan has emphasised the learning aspect of BDD in a wider philosophy which he calls Deliberate Discovery, "as opposed to accidental discovery". He deliberately targets ignorance around our technology, people and process; an ignorance that we always have, despite our best efforts. However, he asks the community to minimise the difference between BDD and TDD or ATDD done well with this request:

"I'd like to avoid "BDD is better than TDD because..." or even "BDD is different from TDD (as originally envisioned) because..." TDD is amazing. Its initial conception was to solve exactly what I've been trying to do with BDD ... It's not the *only* way to come up with good design, and neither is BDD.

BDD is about understanding the customer's need and letting emerging understanding of that need drive the software write ... always trying to gain greater understanding. But I bet that's what Kent Beck would say if you asked him what TDD was all about."