TDD_I_04: Soukromí
$5 + 10 CHF = $10 je-li kurz 2:1
$5 * 2 = $10
Převést položku mnozstvi na soukromou
Vedlejší účinky třídy Dolar?
Zaokrouhlování peněz?
Metoda equals()
Metoda hashCode()
Rovnost s null
Rovnost objektů
Nyní, když jsme definovali metodu equals(), můžeme ji použít k tomu aby naše testy měly vyšší vypovídací hodnotu. Teoreticky by operace Dolar.krat() měla vracet objekt Dolar, jehož hodnota je hodnotou volaného objektu vynásobenou parametrem nasobek. Náš test však přímo neříká že:
public void testNasobeni() { Dolar pet = new Dolar(5); Dolar nasobek ´pet.krat(2); assertEquals(10, nasobek.mnozstvi); nasobek = pet.krat(3); assertEquals(15, nasobek.mnozstvi); }
Tuto první aserci můžeme přepsat tak, aby se porovnávaly dva objekty Dolar.
public void testNasobeni() { Dolar pet = new Dolar(5); Dolar nasobek ´pet.krat(2); assertEquals(new Dolar(10), nasobek); nasobek = pet.krat(3); assertEquals(15, nasobek.mnozstvi); }
To už vypadá líp, tak přepíšeme i druhou aserci:
public void testNasobeni() { Dolar pet = new Dolar(5); Dolar nasobek ´pet.krat(2); assertEquals(new Dolar(10), nasobek); nasobek = pet.krat(3); assertEquals(new Dolar(15), nasobek); }
Nyní je pomocná proměnná nasobek k ničemu, takže ji můžeme vynechat:
public void testNasobeni() { Dolar pet = new Dolar(5); assertEquals(new Dolar(10), pet.krat(2)); assertEquals(new Dolar(15), pet.krat(3)); }
Tento test hovoří jasněji, jako kdyby šlo o pozitivní aserci a nikoli o sled operací.
S výše uvedenými změnami v testu je Dolar ji jedinou třídou, která používá svou instanci proměnné mnozstvi, takže ji můžeme označit jako soukromou:
Dolar
private int mnozstvi;
$5 + 10 CHF = $10 je-li kurz 2:1
$5 * 2 = $10
Převést položku mnozstvi na soukromou
Vedlejší účinky třídy Dolar?
Zaokrouhlování peněz?
Metoda equals()
Metoda hashCode()
Rovnost s null
Rovnost objektů
A můžeme si škrtnout další položku na seznamu úkolů. Všimněte si, že jsme se vystavili riziku. Jestliže test rovnosti selže a neověří přesně že porovnání funguje, pak by mohl selhat i test ověřující násobení. To je riziko, se který s v TDD musíme vypořádat. Nehledáme dokonalost. Tím, že se na vše díváme ze dvou stran - ze strany kódu i ze strany testů - doufáme, že omezíme vlastní selhání do té míry abychom mohli s odvahou pokračovat. Čas od času nás náš způsob myšlení zklame a objeví se chyba. Když k tomu dojde, poučíme se o tom, jaký test jsme měli napsat, a pokračujeme. Ale jinak odvážně kráčíme vpřed pod statečně se třepající vlajkou zeleného ukazatele (můj ukazatel se vlastně netřepotá, ale sny má každý). Abychom si to zopakovali:
- Použili jsme právě vytvořeno funkci ke zlepšení testu.
- Všimli jsme si, že když selžou dva testy současně, jsme v háji.
- Pokračovali jsme navzdory riziku.
- V testovaném objektu jsme použili zbrusu novou funkci, abychom snížili závislost mezi testem a kódem.
Vývoj řízený testy, Kapitola 3 | Dr3dweRkZ | Vývoj řízený testy, Kapitola 5