Redakcja
ATDD jest metodą wytwarzania oprogramownia, w której kluczem do stworzenia linijki kodu jest przygotowany z wyprzedzeniem test napisany przez klienta.
Zakładamy, że w tej praktyce (stosowanej głównie w Agile) cały zespół wspólnie definiuje kryteria akceptacji dla oprogramowania, a następnie tworzy z nich testy akceptacyjne (zanim wytworzony zostanie kod). Podczas wytwarzania kodu programiści automatyzują testy w oparciu o język naturalny zdefiniowany w testach klienta. Dzięki temu testy ATDD stają się wykonywalnymi wymaganiami.
Podstawą do wytworzenia kodu w metodzie Test Driven Development jest jednostkowy przypadek testowy napisany wokół pojedynczego "wymagania". ATDD zakłada, że tym "wymaganiem" może być gotowy test akceptacyjny zbudowany wokół historyjki (user story). Wyjściowa idea jest tutaj prosta: "Daj mi przykład, a ja zacznę to kodować".
Bardzo możliwe, że kiedy czytasz o ATDD masz wrażenie, że jest to to samo co BDD (Behaviour Driven Development) i to samo co Specification by Example. Rzeczywiście, są to bardzo pokrewne praktyki, które aktualnie rozwijają się niezależnie i do czasu, kiedy ich twórcy dojdą do porozumienia powinniśmy je traktować jako rozbieżne.
Warto przeczytać.
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Źródła
http://janetgregory.blogspot.com/2010/08/atdd-vs-bdd-vs-specification-by-example.html
