Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: MiroslavP 22. 10. 2016, 14:20:29
-
Mám třídu A ve které je metoda main, dále třídu B ve druhém souboru, B má nějaký statický veřejný atribut b. Když krokuji metodu main (třídy A), tak se mi nedaří vidět obsah statického atributu b (třídy B), který jsem před tím nastavil na nějakou hodnotu. Mohl byste mi to někdo prosím vysvětlit?
-
Ten atribut je jejpíš privátní a tedy zvenčí neviditelný.
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
-
Co hodit kod na github, at je videt, o co se snazis?
-
Ten atribut je jejpíš privátní a tedy zvenčí neviditelný.
Nepise, ze je verejny?
A mas snad dojem, ze si debugger lame hlavu s tim, co mas private?
-
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
A co dnes tedy používají programátoři tvého kalibru?
-
A co dnes tedy používají programátoři tvého kalibru?
- kávovou sedlinu
- tarotové karty
- kristalovou kouli
-
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.
-
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.
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.
-
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.
-
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
A co dnes tedy používají programátoři tvého kalibru?
Testy.
-
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
A co dnes tedy používají programátoři tvého kalibru?
Testy.
To je zalezitost s naprosto jinym ucelem. (prestoze dobre testy mohou vyrazne zmensit sanci, ze budes debugger potrebovat).
-
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
A co dnes tedy používají programátoři tvého kalibru?
Testy.
To je zalezitost s naprosto jinym ucelem. (prestoze dobre testy mohou vyrazne zmensit sanci, ze budes debugger potrebovat).
Píši tolik testů, abych debugger a krokování vůbec nepotřeboval. Debugování by mě jen zdržovalo.
-
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
A co dnes tedy používají programátoři tvého kalibru?
Testy.
To je zalezitost s naprosto jinym ucelem. (prestoze dobre testy mohou vyrazne zmensit sanci, ze budes debugger potrebovat).
Píši tolik testů, abych debugger a krokování vůbec nepotřeboval. Debugování by mě jen zdržovalo.
Jasne. A kolegove taky nikdy neudelaji chybu. A nikdy neni chyba v knihovne, co pouzivas.
Pro nas ostatni je tu http://debuggingrules.com/
-
Jasne. A kolegove taky nikdy neudelaji chybu. A nikdy neni chyba v knihovne, co pouzivas.
Pro nas ostatni je tu http://debuggingrules.com/
Hlavně nemusím řešit takové ptákoviny jako tazatel, neboť TDD mě od skrytých závislostí odnaučilo vcelku rychle.
Cizí knihovny mám samozřejmě také pokryty vlastními testy.
-
Jasne. A kolegove taky nikdy neudelaji chybu. A nikdy neni chyba v knihovne, co pouzivas.
Pro nas ostatni je tu http://debuggingrules.com/
Hlavně nemusím řešit takové ptákoviny jako tazatel, neboť TDD mě od skrytých závislostí odnaučilo vcelku rychle.
Cizí knihovny mám samozřejmě také pokryty vlastními testy.
A nikdy kolegove neudelaji chybu a vzdy pokryjes vsechno.
-
A nikdy kolegove neudelaji chybu a vzdy pokryjes vsechno.
O co ti jde? Myslíš si snad, že ti krokování v debuggeru při hledání chyby nějak pomůže?
-
Ano, a potom ked refaktorujes alebo prepisujes nejaku core vec, tak stravis 30% casu prepisom a 70% opravou testov (z pravidla od inych ludi).
Cersnickou na torte su take unit testy, ktore su akoze unit, ale v skutocnosti su integracne. Napr. ti startuje in-memory databaza (lebo ved v Spring-u je to tak jednoduche), len aby si nasledne po nasadeni na produkcii zistil, ze HSQL v testoch defaultne nebezi v MVCC a MySql s InnoDB ano....
-
Ano, a potom ked refaktorujes alebo prepisujes nejaku core vec, tak stravis 30% casu prepisom a 70% opravou testov (z pravidla od inych ludi).
Při refaktorování se na testy nesahá. To bys mohl vědět.
Při redesignu prostě opravím test a pak program. Ostatní stráví 20 % času přepisem a 80 % debugováním.
Cersnickou na torte su take unit testy, ktore su akoze unit, ale v skutocnosti su integracne. Napr. ti startuje in-memory databaza (lebo ved v Spring-u je to tak jednoduche), len aby si nasledne po nasadeni na produkcii zistil, ze HSQL v testoch defaultne nebezi v MVCC a MySql s InnoDB ano....
To není unit test, ale integrační. Když si někdo neumí namockovat databázi, tak si nic jiného nezaslouží.
-
A nikdy kolegove neudelaji chybu a vzdy pokryjes vsechno.
O co ti jde? Myslíš si snad, že ti krokování v debuggeru při hledání chyby nějak pomůže?
Ano. Je to jedna z veci, ktere ti mohou pomoci, kdyz s nimi umis. At uz jsi pripojeny k zivemu programu nebo krokujes test.
A jeste jsi neodpovedel, zda i tvoji kolegove produkuji bezchybny a dokonale pokryt kod.
-
A jeste jsi neodpovedel, zda i tvoji kolegove produkuji bezchybny a dokonale pokryt kod.
Když testy procházejí, ale program nefunguje jak má, je nutné opravit testy. To je základní pravidlo.
-
A jeste jsi neodpovedel, zda i tvoji kolegove produkuji bezchybny a dokonale pokryt kod.
Když testy procházejí, ale program nefunguje jak má, je nutné opravit testy. To je základní pravidlo.
To je pulka pravdy.
Druha pulka prvdy je, ze nekdy je dobre se podivat pod kapotu, nez zacnes neco opravovat.
A stale cekam na odpoved o tom, zda kolegove delaji vsechno tak, jak se tady prezentujes sam.
-
A je mi trapne to zduraznovat, ale drzet se nejake ideologie je fain, ale nemela by cloveku zabranit udelat spravnou vec.
-
Druha pulka prvdy je, ze nekdy je dobre se podivat pod kapotu, nez zacnes neco opravovat.
TDD takové jednání připouští pouze v případě, že test selže. Pokud test projde, na program se sahá pouze při refaktorování.
-
Druha pulka prvdy je, ze nekdy je dobre se podivat pod kapotu, nez zacnes neco opravovat.
TDD takové jednání připouští pouze v případě, že test selže. Pokud test projde, na program se sahá pouze při refaktorování.
A kde je tam psano, ze se nesmis podivat, jak to vypada v behu (at uz v behu programu nebo v behu unity pri spusteni testu)?
-
Druha pulka prvdy je, ze nekdy je dobre se podivat pod kapotu, nez zacnes neco opravovat.
TDD takové jednání připouští pouze v případě, že test selže. Pokud test projde, na program se sahá pouze při refaktorování.
Hele, tak mne napada, mas nejake kolegy, ze jo? Nejsi jenom chudak osamely programator, co si mysli, ze to dela dobre, aniz by mel zkusenost z vyssich levelu?
-
Tady něco smrdí. TDD je fajn nápad, ale v praxi nerealizovatelný plně. Takže buď Kit nic nedělá a jen tady píše teorii a nebo si z nás dělá srandu. Testy jsou super, o tom žádná, ale pokud mám desítky tisíc a více řádků kódu, tak testů bude minimálně trojnásobek, což je trochu problematické. Hlavně se se špatně vysvětluje, když ladíš dva týdny testy, abys pak mohl začít implementovat :D
-
Tak co, chlapi, už to funguje?
No, zatím ne, ale máme testy! 8)
-
Druha pulka prvdy je, ze nekdy je dobre se podivat pod kapotu, nez zacnes neco opravovat.
TDD takové jednání připouští pouze v případě, že test selže. Pokud test projde, na program se sahá pouze při refaktorování.
Mám-li něco dodělat do existujícího systému, TDD mi sice přikazuje nejdříve udělat test ale je přeci evidentní že než začnu s implementací změn tak ten test bude selhávat! A pak hned bývá potřeba debugger abych pochopil jak to v tom systému funguje protože často nejsem autorem a dokumentace nikdy není dokonalá a zdaleka ne všechny systémy jsou tak jednoduché aby si stačilo přečíst zdrojáky...
-
Tady něco smrdí. TDD je fajn nápad, ale v praxi nerealizovatelný plně. Takže buď Kit nic nedělá a jen tady píše teorii a nebo si z nás dělá srandu. Testy jsou super, o tom žádná, ale pokud mám desítky tisíc a více řádků kódu, tak testů bude minimálně trojnásobek, což je trochu problematické. Hlavně se se špatně vysvětluje, když ladíš dva týdny testy, abys pak mohl začít implementovat :D
Testy tvořím zároveň s vývojem modulu. Chvilku píši test, chvíli implementaci a střídá se to podle toho, zda ten test projde či nikoli. Je to mnohem praktičtější a je to i podle pravidel TDD. Když mám hotovo, jdu na další modul.
-
Mám-li něco dodělat do existujícího systému, TDD mi sice přikazuje nejdříve udělat test ale je přeci evidentní že než začnu s implementací změn tak ten test bude selhávat! A pak hned bývá potřeba debugger abych pochopil jak to v tom systému funguje protože často nejsem autorem a dokumentace nikdy není dokonalá a zdaleka ne všechny systémy jsou tak jednoduché aby si stačilo přečíst zdrojáky...
Od toho mám přece ten test, aby mi odhalil, v čem je chyba.
-
Tady něco smrdí. TDD je fajn nápad, ale v praxi nerealizovatelný plně. Takže buď Kit nic nedělá a jen tady píše teorii a nebo si z nás dělá srandu. Testy jsou super, o tom žádná, ale pokud mám desítky tisíc a více řádků kódu, tak testů bude minimálně trojnásobek, což je trochu problematické. Hlavně se se špatně vysvětluje, když ladíš dva týdny testy, abys pak mohl začít implementovat :D
Testy tvořím zároveň s vývojem modulu. Chvilku píši test, chvíli implementaci a střídá se to podle toho, zda ten test projde či nikoli. Je to mnohem praktičtější a je to i podle pravidel TDD. Když mám hotovo, jdu na další modul.
OK, to zní dobře. Sice to nejde u všeho, ale lepší než mít nejdřív test a až pak implementaci. Jen to pomalu sklouzává k tomu, že naimplementuju a pak k tomu dodělám test. Takže jsi jen posunul požadavky na testy na velmi vysokou úroveň. Testy by musely být dokonalé, abych zapomněl na debugger. Reálně budou nejen nedokonalé, ale budou i chybět. Takže jsem zase tam, kde jsme byli.
-
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é.
-
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é.
A já si zase nedovedu představit, jak bych to dělal debugováním. Kromě toho nepopisuješ jednotkový, ale systémový test. Když ten selže, je nutné udělat dva integrační testy. Jeden na klienta, druhý na server.
-
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?
-
To bys mohl vědět.
Dakujem za ponaucenie.
-
Jasne. A kolegove taky nikdy neudelaji chybu. A nikdy neni chyba v knihovne, co pouzivas.
Pro nas ostatni je tu http://debuggingrules.com/
Hlavně nemusím řešit takové ptákoviny jako tazatel, neboť TDD mě od skrytých závislostí odnaučilo vcelku rychle.
Cizí knihovny mám samozřejmě také pokryty vlastními testy.
Mas to nekde hozene napriklad na GitHubu, abychom se mohli dozvedet, jak se to ma delat?
-
Kit dle svých slov žádné větší projekty v javě nedělá https://forum.root.cz/index.php?topic=13943.msg180498;topicseen#msg180498 . Diskutovat s ním debugování javy, navíc ve vimu, nedává smysl.
-
Kit dle svých slov žádné větší projekty v javě nedělá https://forum.root.cz/index.php?topic=13943.msg180498;topicseen#msg180498 . Diskutovat s ním debugování javy, navíc ve vimu, nedává smysl.
Veru sa mi zdalo, ze asi nevidel codebase, ktoru pisalo viac ako 6 ludi po dobu 3 rokov a v TDD nemali tak jasno ako on.
-
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.
To je přece také test, pokud to zařadíš do výbavy vývoje aplikace, aby to bylo možné kdykoli spustit.
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?
Ten integrační test si napíši u sebe, viz výše. Není to debugování, protože nehledám chyby na serveru.
-
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.
To je přece také test, pokud to zařadíš do výbavy vývoje aplikace, aby to bylo možné kdykoli spustit.
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?
Ten integrační test si napíši u sebe, viz výše. Není to debugování, protože nehledám chyby na serveru.
- nikdo neříká, že nemůžeš napsat test i po té, co jinak (debugger, kouknutí do logu, intuice...) najdeš chybu
- máš o debuggování omezené představy. Zdaleka to není jenom používání debuggeru ale daleko obecnější projekt
- a co kolegové? Máš?
-
s/projekt/proces/
Pardon.
-
- a co kolegové? Máš?
Zbytečná otázka :D
-
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í.
-
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)
-
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)
Po odhaleni chyby je dobrym zvykem napsat test, ktery tu situaci pokryva.
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?
-
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.
-
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.
-
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 233 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+(231-1).
-
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.
-
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?
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));
}
}
-
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 233 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+(231-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í.
-
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?
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.
-
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.
-
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á.
-
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ů.
-
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.
-
Kit je vyucujici nekde na soukrome vejsce.
-
:)
Hlasy, ver. 2.
-
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.
-
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.
-
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.
Jenze to je dost okrajovy priklad, kdy mas pro jednu appku jednoho zakaznika (to jsou nejaky webovy obchody ze?). V praxi mas X zakazniku s Y konfiguracemi, navic ty chyby jsou skutecne zpusobeny necim, s cim prakticky zadna aplikace a testy nepocitaji.
Namatkou - na chvilku vypadla DNS, zakaznik presunul cast infrastruktury jinam (a stare IP jsou kesovany kdovi kde), ma to na nejake obskurnejsi architekture (s390x je kupodivu stale oblibena), ma tam spesl. nastaveni FW, kratkodoby vypadek NFS, problematika selinuxu, rozjizdi se (z libovolnych dale neovlivnitelnych duvodu) systemovy cas, zakaznik updatoval "neco" v systemu (tech moznych kombinaci balicku jsou miliardy). Takze ve vysledku jsi rad, kdyz jsou ochotni poslat coredump nebo aspon stacktrace. Btw jestli jsi schopny v rozumnem case to vsechno ^ pokryt, aby vysledkem byla i jen pitoma knowledgebase, tak bych pro Tebe mel peknou nabidku :)
-
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.
Čekal jsem, že zrovna ty mi to vyčteš, i když o tom víš prd. Za chvíli se jistě přidá i javaman.
-
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.
-
Čekal jsem, že zrovna ty mi to vyčteš, i když o tom víš prd. Za chvíli se jistě přidá i javaman.
A co mam rict nekomu, kdo tu kazde nedopochopeneho strejdu Boba, aniz by mel za sebou praci v teamu na necem vetsim? nekomu, kdo tu placa nesmysly a radi nepouzivat vcelku uzitecne techniky, jenom protoze jsou v rozporu s jeho ideologii?
-
Jenze to je dost okrajovy priklad, kdy mas pro jednu appku jednoho zakaznika (to jsou nejaky webovy obchody ze?). V praxi mas X zakazniku s Y konfiguracemi, navic ty chyby jsou skutecne zpusobeny necim, s cim prakticky zadna aplikace a testy nepocitaji.
Namatkou - na chvilku vypadla DNS, zakaznik presunul cast infrastruktury jinam (a stare IP jsou kesovany kdovi kde), ma to na nejake obskurnejsi architekture (s390x je kupodivu stale oblibena), ma tam spesl. nastaveni FW, kratkodoby vypadek NFS, problematika selinuxu, rozjizdi se (z libovolnych dale neovlivnitelnych duvodu) systemovy cas, zakaznik updatoval "neco" v systemu (tech moznych kombinaci balicku jsou miliardy). Takze ve vysledku jsi rad, kdyz jsou ochotni poslat coredump nebo aspon stacktrace. Btw jestli jsi schopny v rozumnem case to vsechno ^ pokryt, aby vysledkem byla i jen pitoma knowledgebase, tak bych pro Tebe mel peknou nabidku :)
Většinu z toho mám pokrytu integračními testy, ve kterých mám namockované selhání DNS či databáze, systémový čas si beru z jednoho místa (typicky z databáze), takže chybová hlášení zpravidla odpovídají skutečnému místu vzniku chyby a zákazník si často je schopen zjednat nápravu i bez mé asistence.
-
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.
Čekal jsem, že zrovna ty mi to vyčteš, i když o tom víš prd. Za chvíli se jistě přidá i javaman.
Tak já jsem rád, že dostanu odpovědi alespoň na něco. Celkem se mi to líbí, jen je tam znát, že tomu až tak nerozumíš a zároveň jsi neviděl reálné projekty. Což nesnižuje inspirativnost. Občas to jsou dost píčoviny, ale i tak jsem za to rád. Lepší než tvůj brácha a nebo pologramotný jurdo.
-
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.
Ta chyba mi nešla zreprodukovat, neboť mi Java hlásila chyby syntaxe. Navíc v tom byla hromada externích závislostí, které se mi nechtělo mockovat jen proto, abych někomu něco dokazoval. Na první pohled jsem však viděl souběh a to jsem také napsal.
Na vazby mezi jednotkami jsou integrační testy. Ty dělám samozřejmě také.
-
Ta chyba mi nešla zreprodukovat, neboť mi Java hlásila chyby syntaxe.
Opravdu píšete o tomhle komentáři (https://forum.root.cz/index.php?topic=14092.msg182937#msg182937)? 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.
-
Ta chyba mi nešla zreprodukovat, neboť mi Java hlásila chyby syntaxe.
Opravdu píšete o tomhle komentáři (https://forum.root.cz/index.php?topic=14092.msg182937#msg182937)? 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.
Používám Javu 7.
-
Tak snad na první pohled vidíš lambda výrazy, takže tě nemůže překvapit, že to ve staré javě nezkompiluješ a nemá smysl sem psát hlášku o chybě syntaxe.
-
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:
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ě.
-
Tak snad na první pohled vidíš lambda výrazy, takže tě nemůže překvapit, že to ve staré javě nezkompiluješ a nemá smysl sem psát hlášku o chybě syntaxe.
Máš pravdu. Nepřekvapilo mě to. Přece kvůli této diskuzi nebudu přeinstalovávat JDK.
-
Ta chyba mi nešla zreprodukovat, neboť mi Java hlásila chyby syntaxe.
Opravdu píšete o tomhle komentáři (https://forum.root.cz/index.php?topic=14092.msg182937#msg182937)? 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.
Používám Javu 7.
Facepalm.
-
Používám Javu 7.
...
Už mi to jede, včetně lost i win. Teď už jen k tomu napsat požadované testy...
-
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);
}
}
TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.
-
TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.
No právě, TDD tě donutí k čistějšímu kódu, který je snadno testovatelný a také mnohem lépe čitelný.
-
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.
-
Tak snad na první pohled vidíš lambda výrazy, takže tě nemůže překvapit, že to ve staré javě nezkompiluješ a nemá smysl sem psát hlášku o chybě syntaxe.
Máš pravdu. Nepřekvapilo mě to. Přece kvůli této diskuzi nebudu přeinstalovávat JDK.
Nechci se moc motat do tradičního flameware, ale... používáš windows nebo co?
JDK nemusíš instalovat, stačí jen rozbalit. A možná ještě nastavit PATH ale to je optional - můžeš klidně psát plnou cestu :-)
-
No právě, TDD tě donutí k čistějšímu kódu, který je snadno testovatelný a také mnohem lépe čitelný.
to ano.
kolko ludi mate ale na projekte? podla toho ako odmietate odpovedat ste tam sam a "to se to bádá, to se to pracuje".
-
TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.
No právě, TDD tě donutí k čistějšímu kódu, který je snadno testovatelný a také mnohem lépe čitelný.
To je ve skutecnosti otevrena otazka a nevypada to tak:
https://dl.acm.org/citation.cfm?doid=2961111.2962592
IMO je hlavni trik v tom, ze se automaticky testuje a test first (nebo dokonce TDD) je vhodnejsi varianta jenom nekdy.
-
TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.
No právě, TDD tě donutí k čistějšímu kódu, který je snadno testovatelný a také mnohem lépe čitelný.
To je ve skutecnosti otevrena otazka a nevypada to tak:
https://dl.acm.org/citation.cfm?doid=2961111.2962592
IMO je hlavni trik v tom, ze se automaticky testuje a test first (nebo dokonce TDD) je vhodnejsi varianta jenom nekdy.
Až se to prosadí v praxi, tak tomu uvěřím. Osobně považuji teoretické SW inženýrství za pseudovědu. Každých pár let přijdou s novou zázračnou metodikou, kterou ti stejní lidé po čase zavrhnou a začnou prosazovat něco jiného.
-
TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.
No právě, TDD tě donutí k čistějšímu kódu, který je snadno testovatelný a také mnohem lépe čitelný.
To je ve skutecnosti otevrena otazka a nevypada to tak:
https://dl.acm.org/citation.cfm?doid=2961111.2962592
IMO je hlavni trik v tom, ze se automaticky testuje a test first (nebo dokonce TDD) je vhodnejsi varianta jenom nekdy.
Až se to prosadí v praxi, tak tomu uvěřím. Osobně považuji teoretické SW inženýrství za pseudovědu. Každých pár let přijdou s novou zázračnou metodikou, kterou ti stejní lidé po čase zavrhnou a začnou prosazovat něco jiného.
Pockat, tomu nerozumim. Podle tebe se testovani (a specialne TDD) v praxi neprosadilo?
-
TDD předpokládá, že se píše testovatelný kód. Dobrá zásada je nepoužívat mutable proměnné a raw vlákna.
No právě, TDD tě donutí k čistějšímu kódu, který je snadno testovatelný a také mnohem lépe čitelný.
To je ve skutecnosti otevrena otazka a nevypada to tak:
https://dl.acm.org/citation.cfm?doid=2961111.2962592
IMO je hlavni trik v tom, ze se automaticky testuje a test first (nebo dokonce TDD) je vhodnejsi varianta jenom nekdy.
Až se to prosadí v praxi, tak tomu uvěřím. Osobně považuji teoretické SW inženýrství za pseudovědu. Každých pár let přijdou s novou zázračnou metodikou, kterou ti stejní lidé po čase zavrhnou a začnou prosazovat něco jiného.
Pockat, tomu nerozumim. Podle tebe se testovani (a specialne TDD) v praxi neprosadilo?
Myslel jsem, že ten článek prosazuje TLD a zavrhuje TDD. Nečetl jsem ho.
-
Až se to prosadí v praxi, tak tomu uvěřím. Osobně považuji teoretické SW inženýrství za pseudovědu. Každých pár let přijdou s novou zázračnou metodikou, kterou ti stejní lidé po čase zavrhnou a začnou prosazovat něco jiného.
Tak jako kladivo není univerzálním nářadím, tak ani TDD se nedá univerzálně aplikovat na všechno. Každý vývojář používá určitou kombinaci metodik, které poznal a které se mu osvědčily. Některým dává větší váhu, jiným menší, ale nikdy nepoužívá jen jednu.
-
Minulý příspěvek jsem trochu zvoral, tak to napravuji:
Až se to prosadí v praxi, tak tomu uvěřím. Osobně považuji teoretické SW inženýrství za pseudovědu. Každých pár let přijdou s novou zázračnou metodikou, kterou ti stejní lidé po čase zavrhnou a začnou prosazovat něco jiného.
Tak jako kladivo není univerzálním nářadím, tak ani TDD se nedá univerzálně aplikovat na všechno. Každý vývojář používá určitou kombinaci metodik, které poznal a které se mu osvědčily. Některým dává větší váhu, jiným menší, ale nikdy nepoužívá jen jednu.
-
Pockat, tomu nerozumim. Podle tebe se testovani (a specialne TDD) v praxi neprosadilo?
Já proti TDD nic nemám, jen nevím proč bych měl věřit nějakým metrikám produktivity z podobných článků.
-
Kite, opravdu ti přeju že pracuješ s lidmi, pro lidi, a na projektech kde můžeš díky TDD ignorovat ostatní prostředky jako třeba debuger. Přeju ti abys debuger nemusel použít a věřím že to i dokážeš. Protože debuger opravdu většinou není nenahraditelný, obzvlášť pokud si všechen kód píšeš sám.
Pokud ale toto myslíš vážně, a nepsalo to nějaké tvoje dvojče:
Tak jako kladivo není univerzálním nářadím, tak ani TDD se nedá univerzálně aplikovat na všechno. Každý vývojář používá určitou kombinaci metodik, které poznal a které se mu osvědčily. Některým dává větší váhu, jiným menší, ale nikdy nepoužívá jen jednu.
Tak nechápu tvůj, snad až odpor k debugeru. Možná je nadužívaný, možná že ty se nedostáváš do situací kdy by jsi ho s výhodou použil, ale tvářit se že je obecně k ničemu a deklasovat ho na pouhé krokování, to mi přijde na někoho s tvou reputací a zkušenostmi příliš zjednodušující, a promiň, až "hloupé".
Možná bys mohl napsat nějaký blog nebo tak něco a v něm, nejen pro sebe, utřídit důvody pro a proti používání debugeru.Jistě by pod ním byla také zajímavá diskuze.
Ten bys pak mohl přidávat do svých odpovědí na dotazy, na místo ostentativních výkřiků typu:
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
:(
Věřím že by se tak v mnoha diskuzních vláknech kam přispíváš, uvolnil nejen prostor, ale i zbytečné napětí. A dost možná by to bylo i konstruktivnější a užitečnější mít to na samostatné stránce a né jako offtopic v různých vláknech na různých serverech.
-
Jak snadno se debuguje (základní věci - krokování, sledování hodnot, evaluate kód v aktuálním kontextu rámce, podmíněné breakpointy, watches) java ve vimu?
-
Kite, opravdu ti přeju že pracuješ s lidmi, pro lidi, a na projektech kde můžeš díky TDD ignorovat ostatní prostředky jako třeba debuger. Přeju ti abys debuger nemusel použít a věřím že to i dokážeš. Protože debuger opravdu většinou není nenahraditelný, obzvlášť pokud si všechen kód píšeš sám.
Pokud ale toto myslíš vážně, a nepsalo to nějaké tvoje dvojče:
Tak jako kladivo není univerzálním nářadím, tak ani TDD se nedá univerzálně aplikovat na všechno. Každý vývojář používá určitou kombinaci metodik, které poznal a které se mu osvědčily. Některým dává větší váhu, jiným menší, ale nikdy nepoužívá jen jednu.
Tak nechápu tvůj, snad až odpor k debugeru. Možná je nadužívaný, možná že ty se nedostáváš do situací kdy by jsi ho s výhodou použil, ale tvářit se že je obecně k ničemu a deklasovat ho na pouhé krokování, to mi přijde na někoho s tvou reputací a zkušenostmi příliš zjednodušující, a promiň, až "hloupé".
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.
Díky za tvoji reakci, která mi dává smysl. Používám mnoho různých nástrojů, z nichž některé jsem si napsal sám a dobře mi slouží. Některé by se skutečně daly označit za debuggery, jen se jim tak neříká. Aplikace se snažím psát tak, abych debugování pokud možno nepotřeboval - dělám krátké bloky, málo úrovní zanoření, dbám na dekompozici a zapouzdření, píši prototypy a testy. V jednoduchém kódu je méně šancí, že se v něm ztratíš.
Takže souhlasím s tvým výrokem:... snad až odpor k debugeru. Možná je nadužívaný, možná že ty se nedostáváš do situací kdy by jsi ho s výhodou použil...
Prostě je v mém okolí nadužívaný tak, až mi leze krkem.
-
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
takze kolko ludi mate na projekte?
-
Tak dlouho do Kida hučíme, že debugger má svoje (omezené) použití, až najednou říká to samé.
Comedy Gold.
-
Jak snadno se debuguje (základní věci - krokování, sledování hodnot, evaluate kód v aktuálním kontextu rámce, podmíněné breakpointy, watches) java ve vimu?
Na tohle všechno v pohodě stačí command line rozhraní.
-
Jak snadno se debuguje (základní věci - krokování, sledování hodnot, evaluate kód v aktuálním kontextu rámce, podmíněné breakpointy, watches) java ve vimu?
Na tohle všechno v pohodě stačí command line rozhraní.
Ale musíš dost obětovat. Třebas mouse over nad kódem se zobrazováním hodnot má svoje kouzlo, dokud jsi v "explorativním" módu.
-
Na tohle všechno v pohodě stačí command line rozhraní.
Ale musíš dost obětovat. Třebas mouse over nad kódem se zobrazováním hodnot má svoje kouzlo, dokud jsi v "explorativním" módu.
Ty používáš při programování myš?
-
Na tohle všechno v pohodě stačí command line rozhraní.
Ale musíš dost obětovat. Třebas mouse over nad kódem se zobrazováním hodnot má svoje kouzlo, dokud jsi v "explorativním" módu.
Ty používáš při programování myš?
Zalezi na okolnostech. Pri editaci nebo refaktoringu temer vubec, pri prozkoumavani nekdy ano. Podobne trebas v browseru...
-
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í.
-
co to je zas za klauni tenhlete kit? teoretick, co si precetl knizku a napsal super otestovany tic-tack-toe?
-
co to je zas za klauni tenhlete kit? teoretick, co si precetl knizku a napsal super otestovany tic-tack-toe?
ja bych to nepodcenoval, urcite dela ve velkym teamu a je tam guru
-
co to je zas za klauni tenhlete kit? teoretick, co si precetl knizku a napsal super otestovany tic-tack-toe?
ja bych to nepodcenoval, urcite dela ve velkym teamu a je tam guru
A pristi sprint to tic-tac-toe dodaji.
-
urcite dela ve velkym teamu a je tam guru
to nevieme lebo kit sa vyhyba odpovedi na otazke o velkosti teamu jak kit getterom
alebo existuje zazracny team co vyvija javu bez debuggera bez getterov a setterov vo vime
alebo je to one man show
-
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í.
Jak to myslíš? Testy té komponenty má napsat její autor. Pokud ty potřebuješ testovat svůj kód a ta kompnenta ti překáží, tak ji můžeš nahradit nějakou dummy komponentou. Doporučuji ti něco si o tom přečíst a nechytračit tady s buzením o půlnoci.
-
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í.
Jak to myslíš? Testy té komponenty má napsat její autor. Pokud ty potřebuješ testovat svůj kód a ta kompnenta ti překáží, tak ji můžeš nahradit nějakou dummy komponentou. Doporučuji ti něco si o tom přečíst a nechytračit tady s buzením o půlnoci.
A kdyz jsi ji zdedil po predchozim pachateli?
A nekdy (velmi pravdepodobne ne v tomhle pripade) dava i smysl i napsat si neco malo testu na 3rd party komponenty.
-
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í.
Jak to myslíš? Testy té komponenty má napsat její autor. Pokud ty potřebuješ testovat svůj kód a ta kompnenta ti překáží, tak ji můžeš nahradit nějakou dummy komponentou. Doporučuji ti něco si o tom přečíst a nechytračit tady s buzením o půlnoci.
A kdyz jsi ji zdedil po predchozim pachateli?
A nekdy (velmi pravdepodobne ne v tomhle pripade) dava i smysl i napsat si neco malo testu na 3rd party komponenty.
Reagoval jsem na větu, že v takovém případě je třeba rezignovat na testování.
-
Jak to myslíš? Testy té komponenty má napsat její autor. Pokud ty potřebuješ testovat svůj kód a ta kompnenta ti překáží, tak ji můžeš nahradit nějakou dummy komponentou.
Myslím to tak, jak jsem to v této diskusi několikrát napsal – že testování komponent je jednoduché, ze všech možných testů je to to nejjednodušší testování. Ovšem z toho, že vám procházejí testy komponent, neplyne o funkčnosti programu vůbec nic. Protože program vznikne teprve tehdy, když ty komponenty poskládáte, navzájem je propojíte. Přičemž to propojování zase může být dobře i špatně – to, že propojení fungujících komponent vůbec nezaručuje, že bude fungovat i celek, je klíčová znalost, bez níž nemůžete nic testovat.
Takže postupně. Testy komponenty má napsat autor. Jenže autor napíše testy toho, jak si myslí, že by jeho komponenta měla fungovat. Což je něco jiného, než jak komponenta ve skutečnosti funguje (a tenhle rozdíl se snažíme odhalit pomocí jednotkových testů), a hlavně je to něco jiného, než jak si uživatel myslí, že komponenta funguje (a tohle autorovy testy neodhalí). Konkrétně je to problém rozdílu specifikace a implementace a nejednoznačnosti specifikace (z té nejednoznačnosti mimo jiné plyne, že je lepší, pokud jednotkové testy píše někdo jiný, než autor, protože je jistá šance, že když nejednoznačnou specifikaci jinak pochopí autor implementace a jinak autor testu, implementace pak testem neprojde). Testy jsou svým způsobem také specifikace, jenže uživatel komponenty ji nepoužívá na základě specifikace definované testy, ale na základě specifikace popsané někde v dokumentaci (v lepším případě).
Pokud budu testovat svůj kód, komponenta mi překáží a nahradím ji dummy komponentou (v terminologii testování se používá „mock“ komponenta, česky by se řeklo třeba „falešná“ komponenta), testuju jenom to, zda můj kód funguje s mou představou o fungování té komponenty. Nebo-li neodhalím žádnou chybu plynoucí z toho, že má představa o fungování komponenty je odlišná od toho, jak komponenta doopravdy funguje.
Když to celé dobře dopadne a budu mít kód založený na představě o fungování komponenty, která bude alespoň v rozsahu používání té komponenty odpovídat realitě (což taky nejde 100% otestovat, i když budu mít komponentu dobře testovatelnou), pořád ještě zbývá vazba mezi těmi komponentami. Protože ty komponenty obvykle do sebe nezapadnou tak, jak jsou hotové, ale je potřeba je propojit nějakým kódem. Tenhle kód je závislý na obou komponentách, už jenom proto se bude testovat dost těžko. A často je ten kód velmi závislý na okolním prostředí, což testování ještě dál komplikuje. Aneb když vy mi dáte perfektně otestovanou komponentu, která bude počítat třeba jednoduchý součet, já správně pochopím všechny nuance fungování vaší komponenty, moje mock implementace vaší komponenty se bude chovat úplně stejně, jako vaše komponenta, pořád ještě zdaleka není vyhráno. Protože já tu vaši komponentu budu volat jako webovou službu, nebo pomocí meziprocesové komunikace, nebo třeba jenom ve vícevláknovém prostředí, čímž jste nepočítal – a všechno tohle může tu spolupráci dvou perfektně otestovaných komponent zničit mnoha různými způsoby.
Přičemž shodou okolností tohle propojování komponent tvoří čím dál větší objem napsaného software. Protože těch základních komponent je už spousta a jejich vývoj už se rozhodně nezrychluje. Za to se z těch základních komponent dá skládat čím dál víc různých programů, tedy ten rostoucí objem software mají na svědomí právě ty mezikomponentové vazby. (Proto se taky dnes od spousty programátorů chce, aby uměly ty komponenty spojovat, ale není potřeba, aby je uměly vytvářet. Což někteří programátoři, kteří umějí ty komponenty vytvářet, ale neumějí s nimi dál pracovat, těžce nesou a kompenzují si to tím, že se označují za „opravdové programátory“ a ostatní pak třeba za „lepiče kódu“.) Ty mezikomponentové vazby dnes pořádně testovat neumíme, většinou se snažíme otestovat alespoň něco tak, že to naroubujeme na jednotkové testy, případně použijeme nějaký framework, který ty vazby umožní dělat jednotně a se znovupoužitelným kódem. Což jde ale použít jedině u vlastních komponent v rámci jedné aplikace – když třeba voláte nějakou komponentu jako webovou službu, bez spolupráce protistrany neotestujete skoro nic. Zeptejte se lidí, kteří teď implementují EET do pokladních systémů, jak je to testovatelné – a to EET ještě má alespoň nějaké testovací prostředí.
Snad jsem vám to alespoň trochu objasnil a to, co jste si snad někde přečetl, si teď dokážete lépe srovnat.
Doporučuji ti něco si o tom přečíst a nechytračit tady s buzením o půlnoci.
Až zase někdy narazíte na někoho, kdo tvrdí něco jiného, než vy, a budete mít potřebu ho poučovat, že si má něco přečíst, zvažte variantu, že rozdíl v tvrzeních je způsobený tím, že vy jste si možná něco přečetl, ale nepochopil jste to. Předejdete tak sebeztrapňování, jako se vám to stalo v citovaném komentáři.
Reagoval jsem na větu, že v takovém případě je třeba rezignovat na testování.
Hlavně že jste tam tu větu citoval, že? „Rezignovat na testování“ je něco jiného, než „rezignovat na testování jako ověřování správnosti“.