Pokud znáte TDD, pak ATDD je tak nějak TDD s vyšší úrovní testování a s větším zapojením zainteresovaných stran, jinými slovy je to spíše akceptační testování než unit testing. Pokud se chcete o TDD dozvědět více, pak se podívejte na následující příspěvek:
Acceptance test-driven development (ATDD) je metodika vývoje založená na komunikaci mezi obchodními zákazníky, vývojáři a testery. ATDD zahrnuje mnoho stejných postupů jako specifikace podle příkladů, vývoj řízený chováním (BDD), vývoj řízený příklady (EDD) a vývoj řízený podporou nazývaný také vývoj řízený příběhovými testy (SDD). Všechny tyto postupy pomáhají vývojářům a testerům porozumět potřebám zákazníka před implementací a umožňují zákazníkům, aby mohli konverzovat ve svém vlastním doménovém jazyce.
Široce zavedený v rámci agilních týmů, ATDD je postup, kdy obchodní analytici, vývojáři ,testeři a uživatelé spolupracují na definování kritérií přijatelnosti každého příběhu (nebo funkce) v rané fázi procesu vývoje (Před zahájením kódování). Tento přístup umožňuje všem zúčastněným stranám mít a udržovat stejnou úroveň očekávaných výsledků ještě předtím, než vývojář začne kódovat.
Vím, že jsme všichni slyšeli stereotyp „Vývojáři se nezajímají o specifikaci a testeři nechtějí dělat automatizaci“, ale díky ATDD se ušetří spousta promarněného času a peněz tím, že se vývojáři více zapojí do raných fází specifikace a testeři automatizují akceptační testy.
Jak se ATDD realizuje v „reálném životě?“
Používáte SCRUM? Pokud ano, pak již většinu práce v ATDD děláte. pokud ne, pak následující příklad musí ukojit vaši zvědavost :
Příklad
Předpokládejme, že vlastník produktu nebo klient požadoval v naší mobilní aplikaci následující funkci: „Po přezkoumání tohoto požadavku celým týmem (Business analytik, vývojáři, testeři…) a po doplnění dalších detailů do příběhu nebo funkce budeme mít několik „akceptačních“ nebo „funkčních“ testů podobných tomuto (Upozorňujeme, že se jedná pouze o příklad, mnoho akceptačních testů pro tuto funkci chybí):
- Kritérium přijatelnosti 1: Aplikace volitelně akceptuje přihlašovací jméno/heslo pro přihlášení
- Kritérium přijatelnosti 2: Tlačítko bypass umožňuje uživateli procházet v aplikaci bez přihlášení.
- Kritéria přijatelnosti 3: Při zvoleném obcházení tlačítek aplikace neukládá ani nezobrazuje žádné informace specifické pro uživatele
- Kritéria přijatelnosti 4: Při použití přihlašovacího jména/hesla musí být grafické rozhraní aplikace přizpůsobeno nastavení uživatele.
Přínosy
1- Sladění klienta a prodejce : Tím, že výše uvedená kritéria přijatelnosti jsou vstupní informací, máme nyní (každý člen týmu) jistotu, že aplikace zachová funkčnost přihlášení/hesla a pouze přidá tlačítko, které umožní uživateli obejít přihlašovací obrazovku.
2- Kvalita a hospodárnost: Výše uvedené testy lze snadno automatizovat ještě předtím, než vývojáři začnou kódovat.
3- Doba uvedení na trh: Po implementaci testů mohou vývojáři ověřit požadované úlohy ještě před oznámením, že jsou hotové.
ATDD nevyžaduje žádné specifické nástroje. Je důležité vědět, že NE všechny akceptační testy musí být automatizované. Automatizace testů závisí na více aspektech, jako jsou: technická náročnost, termín a náklady.
Nějaké doporučené nástroje?“
ATDD nevyžaduje žádné konkrétní nástroje. Je důležité vědět, že NE všechny akceptační testy musí být automatizované. Automatizace testů závisí na více aspektech, jako jsou: technická náročnost, termín a náklady.
V této části vám poskytnu pouze přehled nejpoužívanějších automatizačních nástrojů na ATDD:
FitNess: Plně integrovaný samostatný framework pro wiki a akceptační testování
Robot framework: obecný framework pro automatizaci testů pro akceptační testování a vývoj řízený akceptačními testy (ATDD)
Calabash: Automatizované akceptační testování pro mobilní aplikace – Upozorňujeme, že tento framework nemusí podporovat nejnovější verzi operačního systému (nad Android O )