Příspěvky

4186

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 24. 10. 2016, 19:41:53 »

Ano, vadí mi spíš nadužívání debuggeru tam, kde by i primitivní test snadno odhalil chybu. Docela mě baví alergické reakce na mé, často hodně zjednodušující, příspěvky. Stačí se jen zmínit o getterech, MVC, debuggeru či jiném postupu či nástroji, který používám jinak než mainstream a rázem se z toho vyvine vlna nadávek, urážek a pokusů o ponižování. Baví mě utahovat si z blbců, to je vše. Všimni si, že jim nenadávám, ani se je nesnažím urazit. Na to si úplně vystačí sami.

Váš úvodní příspěvek nebyl hodně zjednodušující, váš úvodní příspěvek byl klamný. Teď jste konečně pochopil, že jste přestřelil, tak ze své původní pozice „nenápadně“ couváte. Když jste měl předvést praktický příklad toho, jak to děláte, nejprve jste nepoznal Javu 8, a když jste kód dostal naservírovaný na stříbrném podnose, k napsání testu jste se nějak nedostal.

Kdybyste nástroje používal jinak, než mainstream, a dokázal to předvést a obhájit, bylo by to záslužné. A dalo by se říkat, že si utahujete z blbců, a že na to máte právo, protože tomu rozumíte daleko lépe. Jenže zatím jste nic nepředvedl. Zatím jste ukázal přesně to, kvůli čemu si utahujete z toho mainstreamu – že opakujete nějaké poučky, kterými se ani sám neřídíte. A když je máte aplikovat v praxi, tak to nedokážete.

Přitom zrovna automatizované testování je pořád hodně podceňované. Používat ho není jednoduché, ale spousta problémů se dá odstranit, ví se, jak na to, a jejich odstranění by bylo méně nákladné, než absence automatizovaného testování. Jenže abyste to mohl propagovat, musíte nejprve sám dobře vědět, jaké problémy mohou nastat, jaké předpoklady musí být splněny, aby bylo možné automatizované testování úspěšně používat – a tedy také vědět, kdy je použití automatického testování často obtížné nebo nemožné. Vy se místo toho necháte nachytat na učebnicový příklad, u kterého musí každý, kdo o testování něco ví, okamžitě vypálit – i kdyby ho s tím příkladem vzbudili o půlnoci  –, že testování vyžaduje testovatelné objekty (ne jen kód, ale i komponenty a vyšší úrovně programu) a že závislost na komponentách třetích stran obvykle testování znemožňuje nebo alespoň velmi komplikuje. A že v takovém případě je potřeba rezignovat na testování jako ověřování správnosti a spíš ho brát jako usnadnění debugování.

4187

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 24. 10. 2016, 06:45:22 »

TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.

Kdybyste si přečetl celou diskusi, bavíme se tu o tom, že většina kódu, kterou programátor používá, není jeho kód – takže těžko může ovlivnit jeho testovatelnost. Kit tvrdí, že kód vůbec nedebuguje a na všechny chyby přijde jenom díky testům, tak jsem jenom poprosil o praktickou ukázku. Já si právě také myslím, že TDD má spoustu předpokladů, které bohužel často nejsou splněny – a není jednoduché je splnit, často to ani není možné. Kdyby bylo jednoduché ty předpoklady splnit, měli by všichni pokrytí testy 100 %. Ve skutečnosti není problém TDD psaní testů, ale právě to, jak splnit předpoklady pro použití TDD.

4188

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 19:02:26 »

Používám Javu 7.

Což je vzhledem k vašim komentářům zvláštní, ale dobře, tady to máte přepsané pro Javu 7:

Kód: [Vybrat]

package cz.root.test;

public class Main {

    private String result = "You lost!";

    public Main(final Reporter reporter) {
        new Thread() {
            @Override
            public void run() {
                reporter.report(result);
            }
        }.start();
        result = "You win!";
    }

    public static void main(String[] args) {
        new Main(new Reporter() {
            @Override
            public void report(String message) {
                System.out.println(message);
            }
        });
    }
    
    public interface Reporter {
        void report(String message);
    }
}

Edit 19:05: Doplnil jsem rozhraní Reporter modifikátor public, aby se to dalo použít v jiné třídě.

4189

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 18:44:24 »

Ta chyba mi nešla zreprodukovat, neboť mi Java hlásila chyby syntaxe.

Opravdu píšete o tomhle komentáři? Měl jste zkopírovat kód tak jak je, nijak ho neupravovat a vložit do souboru cz/root/test/Main.java a přeložit ho kompilátorem Java 8. To je dnes aktuální verze.

Navíc v tom byla hromada externích závislostí, které se mi nechtělo mockovat jen proto, abych někomu něco dokazoval.

Už to, že je tam jediný import jediné třídy by vám mohlo napovědět, že tam rozhodně hromada externích závislostí není. A ta jediná závislost, která tam v importech je, je ze standardní knihovny Java 8 SE. Další závislosti jsou na třídách z java.lang, opět součást Java SE.

Na první pohled jsem však viděl souběh a to jsem také napsal.

To „na první pohled jsem viděl“ máte integrované v automatických testech? Že pokaždé, když se spustí build, vzbudí vás to a ukáže vám to kód, abyste na první pohled viděl nebo neviděl souběh? To, že je tam na první pohled viditelná chyba v souběhu je záměr. Já jsem se vás ptal, jak byste na tu chybu přišel pomocí testů, kdybyste o ní nevěděl. To, že je ta chyba vidět na první pohled, vám snad situaci nekomplikuje, ne? Představte si, že je to třída třetí strany, kterou máte použít. Psal jste, že si na externí komponenty píšete testy, abyste ověřil, zda fungují správně – třeba ověřujete, že suma(100, 200) vrátí 300. Zajímá mne, jak by tedy vypadal ten váš test na tuhle třídu.

Na vazby mezi jednotkami jsou integrační testy. Ty dělám samozřejmě také.

Ptal jsem se na příklad s navazováním HTTPS spojení a odpověď jsem nedostal.

4190

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 17:31:24 »

někdo se mě začne na něco vyptávat a já jen trpělivě odpovídám

Škoda že vám ta trpělivost došla zrovna ve chvíli, kdy to začalo být zajímavé a ptal jsem se vás na zcela konkrétní příklad.

Psát jednotkové testy je snadné. Jenže drtivá většinu funkcí dnešního softwaru netvoří ty jednotky, ale ty vazby mezi nimi. A to zatím moc efektivně testovat neumíme.

4191

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 16:02:54 »

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ů.

4192

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 16:00:03 »

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á.

4193

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 15:32:43 »

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));
    }
}

4194

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 15:10:11 »

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).

4195

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 14:29:22 »

To je přece také test, pokud to zařadíš do výbavy vývoje aplikace, aby to bylo možné kdykoli spustit.

Jenže před tím, než bych z toho mohl test udělat, musel bych přijít na to, že problém je zrovna v tomhle. A já se ptám, pomocí jakého testu na to přijdu.

A do výbavy vývoje aplikace to nezařadím, protože zautomatizovat zachytávání a analýzu komunikace Wiresharkem by bylo  neúměrně pracné vzhledem k výslednému efektu.

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.

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í.

4196

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 13:08:05 »

A já si zase nedovedu představit, jak bych to dělal debugováním.

Podívám se na seznam algoritmů, které poslal server, na seznam algoritmů, které podporuje klient, a zjistím, že mají prázdný průnik.

Kromě toho nepopisuješ jednotkový, ale systémový test.

Psal jste, že na chyby v programech přicházíte pomocí testů. O tom, zda jsou jednotkové, integrační nebo systémové nebyla řeč. A já jsem na typ testu také žádný požadavek nekladl, ptal jsem se jen, jak to zjistíte pomocí testů – jaký typ testu si vyberete nechávám na vás.

Když ten selže, je nutné udělat dva integrační testy. Jeden na klienta, druhý na server.

To jako že napíšu třeba na Ministerstvo financí, aby doplnili do serverové části EET integrační test?

4197

Server / Re:Amavisd někdy nepošle mail o odmítnutí

« kdy: 23. 10. 2016, 12:59:08 »

Ale mal by o tom odosielatelovi poslat mail.

Neměl. Ve většině případů to bude e-mail s virem a odesílatel je zfalšovaný. Nechcete, aby váš server rozesílal spam s informací o nepovolené příloze někomu, kdo s tím e-mailem nemá vůbec nic společného.

A to funguje len na urcite servery, neviem podla coho.

Pravděpodobně to posílá pouze na adresy, které ověřil pomocí SPF nebo DKIM. Tam si může být jistý, že adresa odesílatele je správně.

v com by mohol byt problem?

Zatím v ničem, problém by mohl nastat, kdybyste tu správnou konfiguraci změnil.

4198

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 23. 10. 2016, 12:36:02 »

Od toho mám přece ten test, aby mi odhalil, v čem je chyba.

Pořád z toho vašeho popisu nechápu, jak pomocí testů odhalíte a pochopíte princip chyby v cizí knihovně nebo obecně v nějaké externí komponentě, na které váš program závisí. Abych uvedl konkrétní příklad – jak pomocí testů odhalíte, že se nedaří HTTPS spojení navázat proto, že v dané konkrétní situaci je průnik algoritmů použitelných pro šifrování na klientovi a na serveru prázdný. Klient ani server není můj kód, pouze přes API volám služby klienta. Rád bych to uměl jednoduše zjistit pomocí testů, protože debugovat SSL komunikaci není úplně snadné.

4199

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 22. 10. 2016, 15:49:36 »

Když krokuju v metodě main (třída A) a najedu zde kurzorem myši nad B.b, tak se mi v bublině zobrazí pouze MujBalicek.B. Jinak pro atributy z A to funguje normálně, tj. zobrazí se mi přímo hodnota.

Předpokládám, že to bude vlastnost NetBeans. Nevím, jak se to chová v IntelliJ Idea nebo Eclipse, protože jsem asi nikdy nepoužil veřejný statický atribut třídy, do kterého by bylo možné zapisovat. Pro debuggování si ten atribut dejte do „Watches“, a pro zachování srozumitelnosti toho programu a předcházení chybám tu globální proměnnou zrušte a zapouzdřete ji do nějakého objektu, který bude ten stav udržovat, a který předáte těm objektům, které se stavem potřebují pracovat.

4200

Vývoj / Re:Netbeans - základy ladění v Javě

« kdy: 22. 10. 2016, 15:20:26 »

Co znamená „nedaří vidět“? Vidíte tam v debuggeru původní hodnotu, nebo vám debugger hlásí nějakou chybu? V programu tu hodnotu vidíte správně? Asi by pomohlo dát sem ten kód.