Výhody automatického testování zřejmě není potřeba vysvětlovat. Pro testery znamenají zrychlení a usnadnění práce a díky nim se můžeme více soustředit na manuální testy. Jak se ale na automatické testování dívají vývojáři?
Vývoj software není jen o přidávání nových funkcí nebo opravě chyb. Pokud chceme, aby byl projekt stále životaschopný, musíme občas provést "úklid", refaktorovat nebo aktualizovat používané knihovny. To s sebou ale nese také potřebu celý produkt kompletně přetestovat. To může znamenat přípravu nových test casů, určení rozsahu testování. Musíme přemýšlet o tom, co všechno bylo změněno a co mohlo být změnou ovlivněno. Potřebujeme si na testování vyhradit čas. Tím se ale zvyšuje riziko, že něco přehlédneme nebo vynecháme - prostě proto, že nám to nepřijde důležité, nebo že na testování máme jen omezenou dobu. Při častějších změnách se také může snížit pravděpodobnost, že se testování někdo vůbec bude věnovat.
Automatické testování nám dává sebevědomí dělat jakékoli změny. Díky automatizaci se nemusíme bát změn, protože je můžeme v podstatě okamžitě otestovat. Můžeme projekt zlepšovat, na více úrovních a vždy máme přehled o tom, jaké měly změny vliv. Bez vylepšování by projekt brzy začal "hnít".
Manuální i automatické testování samozřejmě stojí peníze. I když se může investice do automatizace zdát vysoká, její návratnost je v podstatě okamžitá. S minimálními náklady pak můžeme přidávat další testy, nebo upravovat stávající. Automatizace pomáhá snižovat náklady a drahocenný čas potom můžeme věnovat podrobnějšímu manuálnímu testování.
Nespornou výhodou je i škálovatelnost. Pokud produkt testujeme na více podporovaných systémech a chceme přidat podporu pro další, víme okamžitě, jak na tom jsme. Při ručním testování by to znamenalo spousty repetitivní práce. Automatické testy můžeme spustit na (v podstatě) neomezeném množství konfigurací.
U automatických testů musíme počítat s tím, že jsou spolehlivé tak, jako je nejméně spolehlivá komponenta v testovacím řetězci. Testy musí být deterministické a náhoda zde nemůže hrát roli. Pokud je nějaký test náhodně vyhodnocován jako chybný, roste pravděpodobnost, že se tak stane s počtem spouštěných testů.
Při vytváření automatických testů je tedy potřeba mít dobré znalosti testovacího systému, vstupních parametrů a konfigurací. Testy by na sobě neměly být závislé a nemělo by záležet na jejich pořadí. Testy by také neměly mít vedlejší efekty, na začátku by mělo být test definovat všechny potřebné prerekvizity a na konci systém vrátit do původního stavu. Větší množství malých a nezávislých testů nám dává větší variabilitu.
Nejlepší je začít ihned. "Jakmile to něco dělá, mělo by to být otestované." Když chceme začít s automatickými testy, je potřeba navrhnout infrastrukturu, strategii a to se nejlépe dělá na začátku projektu společně s plánováním ostatních věci. Pokud už projekt běží, přidává se automatizace hůře.
Připravit nejdříve logiku a potom až testy? To záleží na preferencích vývojáře, nastavení projektu nebo použité technologii. Pořadí je méně důležité, vždy je potřeba myslet na oboje. Někdy je dobré iterovat - při přidávání logiky přemýšlet o tom, jak se bude daná věc testovat. Následně napsat testy a opět se vrátit k logice. A toto opakovat, než jsme s výsledkem spokojení.
Ideálně (automaticky) po každém sestavení projektu (buildu). Vývojář si také testy může spustit ručně po každé změně, které by mohla něco ovlivnit. Důležité je tedy, aby testy byly snadno spustitelné a trvaly přiměřeně dlouhou dobu. Vhodné je mít testy rozdělené do více vrstev tak, aby bylo možné si spustit například jen část z nich.
Honba za 100% pokrytí kódu testy může přinést potíže při refaktoringu – testy mohouzhoršovat možnost systém refaktorovat zevnitř. Velké množství testů může být problém sám o sobě i z toho důvodu, že testy prostě trvají dlouhou dobu. Také to zvyšuje nároky na potřebnou údržbu. Při návrhu testů tedy musíme počítat s prioritizací pokrytí: veřejná rozhraní aplikace, funkcionalita důležití pro business, to jsou místa, které by případné bugy měly velký dopad.
Některé testy můžou ve výsledcích "svítit červeně", to ale nemusí nutně znamenat chybu nebo nemožnost vydání produktu. Některé můžou být známe bugy, někde můžeme například čekat na opravu třetí strany. Je důležité ale vědět, proč tyto testy neprochází. U každého takového testu bychom měli mít možnost přidat poznámku s odůvodněním. Před vydáním verze by samozřejmě takové testy neměly být nebo by jejich množství mělo být minimální. Interpretace výsledků by tak měla být jasná a měli bychom si vystačit s klasickým passed/failed.
