OOP a pravidla pro konstruktor

[BoneFlute]

Ja nedavam za pravdu anonymum... Jen mi prijde, ze se prilis casto unit testy zamenuji za akceptacni.
Podle me to co popisujes jsou opravdu akceptacni testy. Jednim z poznavacich znaku je i to, ze pokud se nezmeni rozhrani, ale jen implementace tak na akceptacni testy nemusim sahat.

No tak to se má samosebou, ne? Unittesty jsou na tu menší část, akceptační jsou skoro u klienta. Když rozbiješ unit, tak rozbiješ akceptační, když nerozbiješ akceptační, tak jsi nerozbil unit.

Oproti tomu unit testy obvykle zmenit musim i pri zmene implementace (beze zmeny rozhrani). Protoze unit testy by mely opravdu testovat tu implementaci.

Co je myšleno tou implementací?

Mám objekt. Jednotkou testování je tento objekt (přesněji, volání metody, nebo řady metod nad jednou instancí objektu). Proto je to jednotkové testování. Ten objekt mi naparsuje text na 70znakové kousky. Pokud by byla pravda, že unittesty testují, zda ten objekt používá utf8-supported string parser, nebo ne, tak k čemu je mi takový test vlastně dobrý? Se ti nedivím, že je pak nepíšeš.
Naopak, já budu testovat, zda mi zohledňuje ty háčky a čárky. Jestli to dělá pomocí funkce str(), nebo random(), nebo magic() to je mě upřímně šumák. Neřeším, a není důvod řešit. Nepřináší to vůbec žádný užitek.

Akceptační testování je například to, že mám systém, který zpracovává utf8. Bude nám tenhle objekt, který utf8 neumí stačit? (Klidně může, když jsme v té části všechny háčky odstranili.)

Jak vím, zda umí utf8? Podle unittestů, nebo podle toho, že volá funkci str_parser_UTF8()? A jak poznám, že str_parser_UTF8() skutečně umí utf8? A tak dále.

Unittesty testují chování jednotky. Implementace zajímá vývojáře.

Kdysi jsem poslouchal nejaky podcast, ale uz si nevzpomenu jaky. A tam vyvojar vysvetloval, ze v ramci unit testu testuje jaky konkretni typ kolekce je pouzit pro privatni field nejakeho objektu. Byla to nejaka life-critical aplikace (software kardiostimulatoru nebo neco podobneho) a oni pomoci tech unit testu vlastne vynucovali hlubsi zamysleni pri zmene  implementace.  Takze nejaky smysl to asi ma.

Já netvrdím, že se takovéhle pitvační testy nemohou v některých, extrémních případech hodit. Ale nejsou to unittesty, a unittesty nejsou akceptační.
V některých případech je psaní unittestů náročné. A tak se buď napíší akceptační testy, které nejsou důsledné, ale stačí, nebo klidně se napíše takováhle prasárna, pak to sice furt není důsledné, ale alespoň je to otestované.

[Reklama]

[balki]

Kit: protože v Javě se na všechno preferuje ten ukecaný složitější způsob.

Houby - pokial nie nejde spravit cez stream a lambdy, tak to nie je JAVA. Lambdy su buducnost.

[anonym]

Kit: protože v Javě se na všechno preferuje ten ukecaný složitější způsob.

Houby - pokial nie nejde spravit cez stream a lambdy, tak to nie je JAVA. Lambdy su buducnost.

Lambda sondu si strč do řiti.

[balki]

Kit: protože v Javě se na všechno preferuje ten ukecaný složitější způsob.

Houby - pokial nie nejde spravit cez stream a lambdy, tak to nie je JAVA. Lambdy su buducnost.

Lambda sondu si strč do řiti.

Agresivita je zbytocna, lambdam skor ci neskor podlahnete. Je to elegantne a netreba potom riesit malichernosti s konstruktormi.

[BoneFlute]

Agresivita je zbytocna, lambdam skor ci neskor podlahnete. Je to elegantne a netreba potom riesit malichernosti s konstruktormi.

Tak lambda je defakto ad-hoc objekt bez setterů, mající právě jednu metodu :-) Co si budem povídat, geniální koncept.

[Reklama]

[JSH]

A realita je taková, jaká je, používá se OOP a možná do toho trochu streamy/linq na zpracování dat.

No jasně. A ty streamy a linq vůbec nejsou funkcionální programování, že?

[anonym]

A realita je taková, jaká je, používá se OOP a možná do toho trochu streamy/linq na zpracování dat.

No jasně. A ty streamy a linq vůbec nejsou funkcionální programování, že?

Ty vole já nevím co lidi s tím funkcionálním programováním mají, když pořád tvrdí, že tak programujou, a přitom jen používají lambdu a streamy. Seber se, běž si zaprogramovat do Prologu a pak znova tvrď, že programuješ funkcionálně v Javě.

[Ondra Satai Nekola]

A realita je taková, jaká je, používá se OOP a možná do toho trochu streamy/linq na zpracování dat.

No jasně. A ty streamy a linq vůbec nejsou funkcionální programování, že?

Ty vole já nevím co lidi s tím funkcionálním programováním mají, když pořád tvrdí, že tak programujou, a přitom jen používají lambdu a streamy. Seber se, běž si zaprogramovat do Prologu a pak znova tvrď, že programuješ funkcionálně v Javě.

Az na to, ze ten Prolog neni funkcionalni... Protoze ne vsechno deklarativni je funkcionalni.

[Kit]

Já netvrdím, že se takovéhle pitvační testy nemohou v některých, extrémních případech hodit. Ale nejsou to unittesty, a unittesty nejsou akceptační.

Těm pitvačním testům se říká developer test a běžně se používají. V Javě nejlépe statickou vnitřní třídou, v ostatních jazycích vloženou metodou, která se pak obvykle musí odstranit (u Dlang nemusí). Jednotkové, integrační, systémové a akceptační testy však zůstávají jako součást životního cyklu projektu.

[BoneFlute]

Az na to, ze ten Prolog neni funkcionalni... Protoze ne vsechno deklarativni je funkcionalni.

Myslím, že Prolog patří hlavně do kategorie Logických jazyků. Ale spíše také, páč deklarativní je.

[listoper]

Tak si myslim, ze mame neshodu v terminologii a nicem jinem.
Tomu cemu ty rikas pitvacni ja rikam unit testy.
Tomu cemu rikas unit testy ja rikam akceptacni (i na urovni testovani jedine metody/funkce).

Snazil jsem se najit pro svou terminologii nejakou solidnejsi oporu ale nenasel jsem. Spis mi prijde, ze terminologie jeste neni ustalena a kazdy si to nazyva jak chce.
Narazil jsem na tohle: https://testing.googleblog.com/2010/12/test-sizes.html
Coz vypada, ze i u google meli v terminologii gulas a tak zavedli uplne "novou": small, medium, large...

[Onestone]

A realita je taková, jaká je, používá se OOP a možná do toho trochu streamy/linq na zpracování dat.

No jasně. A ty streamy a linq vůbec nejsou funkcionální programování, že?

Ty vole já nevím co lidi s tím funkcionálním programováním mají, když pořád tvrdí, že tak programujou, a přitom jen používají lambdu a streamy. Seber se, běž si zaprogramovat do Prologu a pak znova tvrď, že programuješ funkcionálně v Javě.

Prolog není funkcionální. Ale někdo už vymyslel λ-prolog.

[BoneFlute]

Tak si myslim, ze mame neshodu v terminologii a nicem jinem.
Tomu cemu ty rikas pitvacni ja rikam unit testy.
Tomu cemu rikas unit testy ja rikam akceptacni (i na urovni testovani jedine metody/funkce).

Snazil jsem se najit pro svou terminologii nejakou solidnejsi oporu ale nenasel jsem. Spis mi prijde, ze terminologie jeste neni ustalena a kazdy si to nazyva jak chce.
Narazil jsem na tohle: https://testing.googleblog.com/2010/12/test-sizes.html
Coz vypada, ze i u google meli v terminologii gulas a tak zavedli uplne "novou": small, medium, large...

Tak může být.

Já jsem se zatím setkal s tím, že programátoři píší testy, kdy testují chování jednotek, to jest tříd, nebo funkcí. Většinou jsme tomu říkali jednotkové testování. JUnit, NUnit, ... Cílem bylo zjistit, zda všechny stavy toho objektu dělají to co chceme. Tím že se to zapíše do testu se navíc toto chování zakonzervuje. V některých jazycích takových testů potřebuješ méně (Haskell), v některých musíš testovat úplně všechno (Javascript, Python).

Pak jsem se setkal s tím, že máš nějakou velkou legaci obludu, a začíná se ti to rozpadat pod rukama. Tak se dělají akceptační testy třeba na web pomocí Selenia. Nebo jsem psal testy na konzolovou aplikaci, což znamenalo, že jsem si testem vytvořil prostředí, spustit apku s vhodnými argumenty, a pak zjišťoval, co vypotila.

Rozdíl oproti těm předchozím je v tom, že jen obtížně pokryješ všechny možné scénáře. Což v legaci kódu už jen pár testů pomůže. A vůbec obecně netestuješ jednu jednotku, ale spíše harmonii všech těch jednotek, které tvoří aplikaci.

Ano, dalo by se uvažovat tak, že ty akceptační jsou vlastně jen ty jednotkové ve větším, protože když testuješ objekt, tak on taky jen deleguje práci na další své závislosti a tak. Rozdíl ale vidím v tom, že nikdo soudný nevytváří objekty v těch objektech ručně, ale předává je jako závislost - tudíž testuješ čistě a pouze interakci toho objektu s těmi závislostmi. A při testech jsou ty závislosti namockované. Zatímco v těch akceptačních testech testuješ, zda skutečně proběhl zápis do databáze, vytvořil se soubor, odeslal se mail. Testuješ, zda proběhnou všechny ty interakce v té hromadě provázaných objektů. V jednotkovém testu testuješ jen zda se správně zeptal té namockované závislosti.

Jak tomu pak říkat, je jiná věc :-)

[SB]

Ja nedavam za pravdu anonymum... Jen mi prijde, ze se prilis casto unit testy zamenuji za akceptacni.
Podle me to co popisujes jsou opravdu akceptacni testy. Jednim z poznavacich znaku je i to, ze pokud se nezmeni rozhrani, ale jen implementace tak na akceptacni testy nemusim sahat.
Oproti tomu unit testy obvykle zmenit musim i pri zmene implementace (beze zmeny rozhrani). Protoze unit testy by mely opravdu testovat tu implementaci.
Kdysi jsem poslouchal nejaky podcast, ale uz si nevzpomenu jaky. A tam vyvojar vysvetloval, ze v ramci unit testu testuje jaky konkretni typ kolekce je pouzit pro privatni field nejakeho objektu. Byla to nejaka life-critical aplikace (software kardiostimulatoru nebo neco podobneho) a oni pomoci tech unit testu vlastne vynucovali hlubsi zamysleni pri zmene  implementace.  Takze nejaky smysl to asi ma. Ale jak jsem psal sam to nedelam (moje aplkace nejsou life-critical). Pisu jen akceptacni testy a rikam jim akceptacni testy. Stydel bych se je nazyvat unit testy...

Obávám se, že to, co popisujete, je jen čísi interpretací. Původní SUnit vznikl pro účely TDD, které samo o sobě metodicky a z podstaty testuje objekty pouze zvenku. Tolik k původní koncepci.

[SB]

Tak lambda je defakto ad-hoc objekt bez setterů, mající právě jednu metodu :-) Co si budem povídat, geniální koncept.

To nemusí být vůbec pravdou, záleží na implementaci. Mimoto je docela obvyklým nedostatkem nerozlišovat lambdy a uzávěry.