Základy programovaní 3 - Java. Unit testy. Petr Krajča. Katedra informatiky Univerzita Palackého v Olomouci. 26.,27.

Transkript

1 Základy programovaní 3 - Java Unit testy Petr Krajča Katedra informatiky Univerzita Palackého v Olomouci 26.,27. listopad, 2014 Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

2 Testování zásadní část vývojového cyklu často z mnoho důvodů podceňovaná protože: není na to čas,,vždyt mě to funguje, zkoušel jsem to zákazník to stejně nepozná, když to trochu ošidíme testování je nudné, psát kód je větší zábava atd. řada přístupů k testování od modelu vodopád až k testy řízenému vývoji TDD od ad hoc testů k automatickým při volbě správného přístupu je postačující/vhodné/nutné používat zdravý rozum Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

3 Druhy testů ad hoc testování unit (jednotkové) testy testování nejmenších částí kódu integrační testy testuje rozhraní mezi jednotlivými částmi systému systémové testy ověřují funkčnost systému jako celku a další akceptační, regresní testy; alfa, beta testování Omezení nelze otestovat vše lze pouze dokázat přítomnost chyby, ne správnost programu problémy s testováním interagujících částí (UI, databáze, atd.) Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

4 Druhy testů ad hoc testování unit (jednotkové) testy testování nejmenších částí kódu integrační testy testuje rozhraní mezi jednotlivými částmi systému systémové testy ověřují funkčnost systému jako celku a další akceptační, regresní testy; alfa, beta testování Omezení nelze otestovat vše lze pouze dokázat přítomnost chyby, ne správnost programu problémy s testováním interagujících částí (UI, databáze, atd.) Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

5 Ideální test s nějakou formou testování se setkal asi každý bylo to dobře provedené testování? byl to produktivně strávený čas? nemohl by to udělat někdo jiný? = automatické testování Dobrý (automatický) test rychle napsaný = nechceme s nimi ztrácet čas srozumitelný = chceme testům rozumět rychlý = chceme dělat testy často (kdykoliv je to potřeba) Proč (automaticky) testovat aplikace? ověření, že všechno dělá, co má možnost zjistit, že změna v jedné části nerozbila jinou část příležitost změnit implementaci bez změny rozhraní (refactoring) forma dokumentace Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

6 Ideální test s nějakou formou testování se setkal asi každý bylo to dobře provedené testování? byl to produktivně strávený čas? nemohl by to udělat někdo jiný? = automatické testování Dobrý (automatický) test rychle napsaný = nechceme s nimi ztrácet čas srozumitelný = chceme testům rozumět rychlý = chceme dělat testy často (kdykoliv je to potřeba) Proč (automaticky) testovat aplikace? ověření, že všechno dělá, co má možnost zjistit, že změna v jedné části nerozbila jinou část příležitost změnit implementaci bez změny rozhraní (refactoring) forma dokumentace Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

7 Ideální test s nějakou formou testování se setkal asi každý bylo to dobře provedené testování? byl to produktivně strávený čas? nemohl by to udělat někdo jiný? = automatické testování Dobrý (automatický) test rychle napsaný = nechceme s nimi ztrácet čas srozumitelný = chceme testům rozumět rychlý = chceme dělat testy často (kdykoliv je to potřeba) Proč (automaticky) testovat aplikace? ověření, že všechno dělá, co má možnost zjistit, že změna v jedné části nerozbila jinou část příležitost změnit implementaci bez změny rozhraní (refactoring) forma dokumentace Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

8 Unit testy testují se nejmenší části programu (obsahující nějakou logiku) nejčastěji jednotlivé metody/funkce na základě jejich specifikace očekáváme určite chování (contract) např. na základě vstupů očekáváme specifikovaný výstup/změnu stavu objektu testy by měli být,,hloupé a neobsahovat vlastní,,logiku (různé výpočty, if, for, switch) = riziko vytvoření špatného testu měly by být testovány i mezní případy Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

9 Frameworky psaní testů by mělo být co nejpohodlnější třídy obsahující metody provádějící jednotlivé testy vyznačeny s pomocí anotací jestli je daný test splněn je dáno pomocí jednotlivých tvrzení (assertions) assertequals(expected, actual) asserttrue(condition)... pro zjednodušení se používají frameworky JUnit, NUnit, atd. = možnost integrace v IDE Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

10 Příklad použití (1/2) public class Counter { private int state = 0; public Counter() { super(); public void add() { this.state++; public int getvalue() { return this.state; Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

11 @Test public void basictest2() { Counter c = new Counter(); c.add(); c.add(); Assert.assertEquals(2, c.getvalue()); Petr Krajča (UP) Unit testy 26.,27. listopad, / 14 Příklad použití (2/2) import org.junit.assert; import org.junit.test; public class CounterTest public void basictest1() { Counter c = new Counter(); c.add(); Assert.assertEquals(1, c.getvalue());

12 Možné vylepšení a úskaĺı společná inicializace: metody společný,,úklid : metody Co všechno testovat? všechny funkce mající veřejné rozhraní (public metody) nemá smysl testovat soukromé metody ALE! testy by měly projít většinu řádků kódu nemá smysl testovat funkci primitivních getterů/setterů ALE! má smysl testovat důsledky jejich změny Kdy psát unit testy? pokud to jde, před psaním kódu pokud to nejde, je dobré ověřit, že nový test funguje při objevení chyby a před její opravou Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

13 Možné vylepšení a úskaĺı společná inicializace: metody společný,,úklid : metody Co všechno testovat? všechny funkce mající veřejné rozhraní (public metody) nemá smysl testovat soukromé metody ALE! testy by měly projít většinu řádků kódu nemá smysl testovat funkci primitivních getterů/setterů ALE! má smysl testovat důsledky jejich změny Kdy psát unit testy? pokud to jde, před psaním kódu pokud to nejde, je dobré ověřit, že nový test funguje při objevení chyby a před její opravou Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

14 Možné vylepšení a úskaĺı společná inicializace: metody společný,,úklid : metody Co všechno testovat? všechny funkce mající veřejné rozhraní (public metody) nemá smysl testovat soukromé metody ALE! testy by měly projít většinu řádků kódu nemá smysl testovat funkci primitivních getterů/setterů ALE! má smysl testovat důsledky jejich změny Kdy psát unit testy? pokud to jde, před psaním kódu pokud to nejde, je dobré ověřit, že nový test funguje při objevení chyby a před její opravou Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

15 Přetečení do integračních testů každý unit test by měl testovat jednu věc = problém těsně propojených komponent unit test by neměl interagovat s okoĺım (sít, souborový systém, databáze) = zpomalení testů, nutnost připravit prostředí, není zaručené, že test uspěje, když má vytvoření maket objektů oddělení integračních testů = možnost použít stejné nástroje jak pro unit testy pokud je potřeba složitá inicializace = zřejmě špatný unit test Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

16 Nevhodný test (1/2) Metoda třídy Board public List<Move> getalllegalmoves(piece p) { List<Move> result = LinkedList<Move>(); for (int i = 0; i < 8; i++) for (int j = 0; j < 8; j++) { Move m = new Move(p.getPosition(), new Position(i, j)); if (this.islegalmove(m)) result.add(m); return result; Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

17 Nevhodný test public void testalllegalmoves1() { Board b = createboard(); Piece p = b.getpiece(...); List<Move> moves = b.getalllegalmoves(p); for (Move m: moves) Assert.assertTrue(b.isLegalMove(m)); Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

18 Testování práce se soubory (1/2) Jako integrační public void setup() throws IOException { Board b = createboard(); public void teardown() throws IOException { File f = new File("/tmp/foo"); public void loadtest1() { Board b = Board.loadBoard("/tmp/foo"); //... Petr Krajča (UP) Unit testy 26.,27. listopad, / 14

19 Testování práce se soubory (2/2) Problémy 1 magické hodnoty 2 testují se dvě různé věci: uložení i načtení 3 zápis na disk může selhat (práva, zaplnění, atd.) Řešení 1 použití konstant 2 místo uložení pomocí saveboard zapsat test přímo 3 upravit čtení, aby nepotřebovalo přístup na disk public static Board load(inputstream stream) {... Board b1 = Board.load(new FileInputStream("/tmp/blah"); Board b2 = Board.load(new StringInputStream("<?xml..."); Petr Krajča (UP) Unit testy 26.,27. listopad, / 14