Netbeans - základy ladění v Javě

[Kit]

Ale jeste jednou, at to zvladnes i ty:
Prisla ti chyba. Od QA nebo z produkce od zakaznika. Pochopitelne je to chyba razeni "to se nemuze stat".
Co udelas? Napises test? Nebo udelas neco pred tim?

Tu chybu od zákazníka podle jeho popisu vstupních podmínek nacpu do testů a budu se ji snažit zreplikovat. Ve chvíli, kdy test neprojde, už vím, co mám kde opravovat.

[Reklama]

[Ondra Satai Nekola]

Ale jeste jednou, at to zvladnes i ty:
Prisla ti chyba. Od QA nebo z produkce od zakaznika. Pochopitelne je to chyba razeni "to se nemuze stat".
Co udelas? Napises test? Nebo udelas neco pred tim?

Tu chybu od zákazníka podle jeho popisu vstupních podmínek nacpu do testů a budu se ji snažit zreplikovat. Ve chvíli, kdy test neprojde, už vím, co mám kde opravovat.

Tak tohle ti zdaleka vzdycky neprojde. Pocinaje tim, ze nemusis mit ty same konfigurace, co ma zakaznik, a konce tim, ze proste nedostanes v reportu dost informaci.

[Filip Jirsák]

Ten integrační test si napíši u sebe, viz výše. Není to debugování, protože nehledám chyby na serveru.

Ona to klidně i může být chyba na serveru. A na začátku debugování už vůbec nevím, kde je chyba – kdybych to věděl, nepotřeboval bych to debugovat.

Nehledám chybu na serveru, ale pomocí testu ověřuji funkčnost, kterou od něj požaduji.

Což je ostatně rozdíl mezi psaním testů a debugováním. Testy se píšou na známé chyby, debugují se neznámé chyby. Samozřejmě to není nějaká pevná hranice, když budu nějakou chybu předpokládat, stane se z neznámé chyby chyba známá a pokud to bude rozumné, napíšu na ni test. Jenže skutečnost, že v programech jsou chyby, svědčí o tom, že programátoři nedokážou předvídat všechny chyby – a že tedy existují i chyby neznámé, které je potřeba teprve objevit. A k tomu docela často pomáhá debugování.

Testy se nepíší na chyby, ale na funkčnost - včetně limitních hodnot a nadlimitních hodnot. Testy předpokládají, že se implementace chová přesně jak se od ní očekává. Výsledky se kontrolují buď automaticky, anebo vizuálně (např. pohledem na vygenerované PDF)

Kdybyste psal testy na požadovanou funkčnost, nenapíšete nikdy ani čárku výkonného kódu, protože byste psal pořád jenom testy a nikdy byste nebyl hotový. Jenom kdybyste chtěl napsat testy na funkčnost primitivní funkce na součet dvou integerů, musel byste napsat 2³³ testů, pokud byste chtěl opravdu úplně otestovat funkčnost. Ve skutečnosti ale napíšete nanejvýš pár testů, které otestují určité případy jako zástupce určité skupiny zadání. Například budete předpokládat, že by chyba mohla být v práci se znaménkem, tak vyzkoušíte sečíst dvě kladná čísla, jedno kladné a jedno záporné a dvě záporná čísla. A budete předpokládat, že když vám to správně sčítá 2+3, bude to správně sčítat i 3+2 nebo 2+4, protože pokud by v kódu byla nějaká chyba, která by se projevila při sčítání 3+2 nebo 2+4, projevila by se i u 2+3. Samozřejmě musíte umět odhadnout ty možné typy chyb, protože 2+3 už by se mělo chovat jinak, než 2+(2³¹-1).

[Kit]

Ale jeste jednou, at to zvladnes i ty:
Prisla ti chyba. Od QA nebo z produkce od zakaznika. Pochopitelne je to chyba razeni "to se nemuze stat".
Co udelas? Napises test? Nebo udelas neco pred tim?

Tu chybu od zákazníka podle jeho popisu vstupních podmínek nacpu do testů a budu se ji snažit zreplikovat. Ve chvíli, kdy test neprojde, už vím, co mám kde opravovat.

Tak tohle ti zdaleka vzdycky neprojde. Pocinaje tim, ze nemusis mit ty same konfigurace, co ma zakaznik, a konce tim, ze proste nedostanes v reportu dost informaci.

Zpravidla mi popis chyby od zákazníka stačí, jeho konfiguraci mívám namockovanou, takže s tím nebývá problém. Pokud v to reportu nedostanu dost informací, vyptám si další, nechám si poslat logy apod.

[Filip Jirsák]

Zpravidla mi popis chyby od zákazníka stačí, jeho konfiguraci mívám namockovanou, takže s tím nebývá problém. Pokud v to reportu nedostanu dost informací, vyptám si další, nechám si poslat logy apod.

Jak byste tedy napsal test a odhalil pomocí něj chybu v následujícím programu, když by vám zákazník reklamoval, že prohrál, přestože mu autor tvrdil, že pokaždé vyhraje?

Kód: [Vybrat]

package cz.root.test;

import java.util.function.Consumer;

public class Main {

    private String result = "You lost!";

    public Main(Consumer<String> action) {
        new Thread(() -> action.accept(this.result)).start();
        result = "You win!";
    }

    public static void main(String[] args) {
        new Main((result) -> System.out.println(result));
    }
}


[Reklama]

[Kit]

Kdybyste psal testy na požadovanou funkčnost, nenapíšete nikdy ani čárku výkonného kódu, protože byste psal pořád jenom testy a nikdy byste nebyl hotový. Jenom kdybyste chtěl napsat testy na funkčnost primitivní funkce na součet dvou integerů, musel byste napsat 2³³ testů, pokud byste chtěl opravdu úplně otestovat funkčnost. Ve skutečnosti ale napíšete nanejvýš pár testů, které otestují určité případy jako zástupce určité skupiny zadání. Například budete předpokládat, že by chyba mohla být v práci se znaménkem, tak vyzkoušíte sečíst dvě kladná čísla, jedno kladné a jedno záporné a dvě záporná čísla. A budete předpokládat, že když vám to správně sčítá 2+3, bude to správně sčítat i 3+2 nebo 2+4, protože pokud by v kódu byla nějaká chyba, která by se projevila při sčítání 3+2 nebo 2+4, projevila by se i u 2+3. Samozřejmě musíte umět odhadnout ty možné typy chyb, protože 2+3 už by se mělo chovat jinak, než 2+(2³¹-1).

Netestuji procesor, ale funkci. Pro funkci součtu stačí do testu zařadit okrajové podmínky, kdy ta funkce musí fungovat správně. Pokud funkce suma(100, 200) vrátí místo 300 hodnotu 44, tak je jasné, že se pro můj účel nehodí, i když pro jiné použití ten výsledek 44 může být správně. Pokud je to externí funkce, musím ji nahradit vlastní implementací.

[Kit]

Zpravidla mi popis chyby od zákazníka stačí, jeho konfiguraci mívám namockovanou, takže s tím nebývá problém. Pokud v to reportu nedostanu dost informací, vyptám si další, nechám si poslat logy apod.

Jak byste tedy napsal test a odhalil pomocí něj chybu v následujícím programu, když by vám zákazník reklamoval, že prohrál, přestože mu autor tvrdil, že pokaždé vyhraje?

Kód: [Vybrat]

package cz.root.test;

import java.util.function.Consumer;

public class Main {

    private String result = "You lost!";

    public Main(Consumer<String> action) {
        new Thread(() -> action.accept(this.result)).start();
        result = "You win!";
    }

    public static void main(String[] args) {
        new Main((result) -> System.out.println(result));
    }
}


Hlavně bych to takhle nikdy nenapsal, neboť v tom jasně vidím souběh.

[Ondra Satai Nekola]

Ale jeste jednou, at to zvladnes i ty:
Prisla ti chyba. Od QA nebo z produkce od zakaznika. Pochopitelne je to chyba razeni "to se nemuze stat".
Co udelas? Napises test? Nebo udelas neco pred tim?

Tu chybu od zákazníka podle jeho popisu vstupních podmínek nacpu do testů a budu se ji snažit zreplikovat. Ve chvíli, kdy test neprojde, už vím, co mám kde opravovat.

Tak tohle ti zdaleka vzdycky neprojde. Pocinaje tim, ze nemusis mit ty same konfigurace, co ma zakaznik, a konce tim, ze proste nedostanes v reportu dost informaci.

Zpravidla mi popis chyby od zákazníka stačí, jeho konfiguraci mívám namockovanou, takže s tím nebývá problém. Pokud v to reportu nedostanu dost informací, vyptám si další, nechám si poslat logy apod.

Když máš něco namockovaného, tak máš namockovanou jenom svou představu o tom něčem.

[Filip Jirsák]

Netestuji procesor, ale funkci.

Takže netestujete funkčnost, ale potenciální chyby.

Pro funkci součtu stačí do testu zařadit okrajové podmínky, kdy ta funkce musí fungovat správně. Pokud funkce suma(100, 200) vrátí místo 300 hodnotu 44, tak je jasné, že se pro můj účel nehodí, i když pro jiné použití ten výsledek 44 může být správně.

Jenže ta funkce vám klidně pro suma(100, 200) může vrátit 300, ale pro suma(200, 100) vám vrátí 44. I když bude procesor v pořádku. Bez pohledu do zdrojáků to nepoznáte, a z vašeho testu assert suma(100, 200) == 300 to také nepoznáte. Protože netestujete funkčnost, ale jenom potenciální chyby – a s chybou, která bude pro vstup 200, 100 vracet špatný výsledek, jste nepočítal.
A přesně tyhle „hm, to by mne nenapadlo, že tam může  být takováhle chyba“ se pak projevují jako chyba programu u koncového uživatele. Když se o ní programátor dozví, někdy už ze samotného výskytu chyby pozná, v čem je problém, ale ty záludnější chyby jsou záludné právě v tom, že jejich příčina není na první pohled vidět. A právě procesu hledání takových chyb se říká debugování. Přičemž testy vám v tom moc nepomůžou – můžete si napsat integrační test na celek, který vám bude padat, ale z toho stejně nezjistíte, proč padá. Abyste mohl napsat jednotkový test na tu konkrétní chybnou funkci, musíte nejprve zjistit, v čem přesně chyba spočívá.

[Filip Jirsák]

Hlavně bych to takhle nikdy nenapsal, neboť v tom jasně vidím souběh.

Já jsem nepsal nic o tom, že byste to takhle napsal. Máte takovýhle kód, třeba v knihovně třetí strany ke které ani nemáte zdrojáky. Psal jste, že ve vašem kódu vše řešíte testováním, tak by mne zajímalo, jak byste řešil tenhle případ. Druhá možnost samozřejmě je, že žádný cizí kód nepoužíváte a vše si píšete od nuly, to jsou pak ale vaše rady nepoužitelné pro drtivou většinu programátorů.

[dustin]

Jistěže jsou nepoužitelné, když Kit žádné větší projekty v javě nepíše. Nechápu, proč se pořád k javě vyjadřuje, nemá vůbec smysl to tady řešit.

[to_je_jedno]

Kit je vyucujici nekde na soukrome vejsce.

[hawran diskuse]

 
Hlasy, ver. 2.

[Kit]

Jistěže jsou nepoužitelné, když Kit žádné větší projekty v javě nepíše. Nechápu, proč se pořád k javě vyjadřuje, nemá vůbec smysl to tady řešit.

Většinou se jen vyjádřím k tématu, pak v BTW něco prohodím (jako např. tady), někdo se mě začne na něco vyptávat a já jen trpělivě odpovídám. Pokud nechcete číst mé odpovědi, tak se mě na nic neptejte a budete mít klid.

[Ondra Satai Nekola]

Jistěže jsou nepoužitelné, když Kit žádné větší projekty v javě nepíše. Nechápu, proč se pořád k javě vyjadřuje, nemá vůbec smysl to tady řešit.

Většinou se jen vyjádřím k tématu, pak v BTW něco prohodím (jako např. tady), někdo se mě začne na něco vyptávat a já jen trpělivě odpovídám. Pokud nechcete číst mé odpovědi, tak se mě na nic neptejte a budete mít klid.

Tezko neodpovedet, kdyz systematicky kazes bludy.