OOP a pravidla pro konstruktor

[anonym]

Kód: [Vybrat]

	XmlDocument doc = new XmlDocument();  
        doc.LoadXml(xmlFile);  

Uz jenom to new XmlDocument() smrdi...

Satai tak teď sis naběhl, vždyť to je z .NETu A pochybuju, že budeš lepší designeři .NETu, to budou lidi jako je Joshua Bloch, chytří a zkušení jako sfiňa.

[Reklama]

[listoper]

Ano, private field zvenčí neexistuje, ale doprčic, NE PRO UNIT TESTY! To je úplně normální a NUTNÉ, že máš třídu a v ní jako private atribut něco, co musíš namockovat.

Privátní field unit testy netestují a ani by neměly. Testuješ kontrakt - veřejné rozhraní a mockuješ okolí třídy: parametry konstruktoru, parametry veřejných metod, případně veřejné rozhraní jiných tříd.

Ale jo mely.
Akceptacni testy testuji rozhrani a tim padem overuji pouzitelnost v kontextu aplikace.
Unit testy - testuji jednotku. tudiz vnitrni implementaci a strukturu testovaneho objektu.
Casto se to plete dohromady.
https://www.lucassaldanha.com/unit-tests-vs-acceptance-tests/

Doznani: Unit testy nepisu. Je to moc slozite(A jeste slozitejsi udrzovat). Akceptacni testy vetsinou staci(aspon u mych projektu to tak bylo vzdy)

[kimec]

Došel jsem ze zkušeností k tomu, že konstruktor je třeba výlučně používat pouze k nasetování stavu objektu. Je chyba v konstruktoru provádět jakékoliv výpočty atp., vždycky jsem se tím dostal do problémů a musel jsem to refaktorovat. Máte stejný poznatek? A pokud ano, jak jste na to přišli? Nečetl jsem o tom nikdy v žádné literatuře a přitom mi to přijde jako důležité pravidlo.

Mate pravdu.  V Jave napr. treba prihliadat aj na suvislosti, ktore vyplyvaju z JMM - garancia immutability atd.
 
Inak povedane, v konstruktore by sa nemalo diat nic, co sposobuje side effecty, t.j. I/O, zmeny shareovaneho stavu, potencialne leakovania nedoinicializovanych objektov inym vlaknam atd.

[gll]

Satai tak teď sis naběhl, vždyť to je z .NETu A pochybuju, že budeš lepší designeři .NETu, to budou lidi jako je Joshua Bloch, chytří a zkušení jako sfiňa.

Joshua Bloch v Efektive Java doporučuje faktory metody.

[n]

Přesně! Je to objekt bez obecného použití! Konečně! Jsme obklopeni objekty bez obecného použití!

1. Třeba tohle je přesně ten shit, který nechci dělat:

Kód: [Vybrat]

	DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
	DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
	Document doc = dBuilder.parse(xmlFile);

2. Proč, když to jde takhle jednoduše:

Kód: [Vybrat]

	XmlDocument doc = new XmlDocument();  
        doc.LoadXml(xmlFile);  

A že není 2 tak obecná? Dpč, 99,5% případů užití je jen pro ten příklad č. 2!

Pak si ale nestěžujte, že nemůžete objekt použít i s jinými závislostmi, např. právě tím mockem při testech (kdy test je jen speciálním použitím obecného objektu).

A mne by se libilo:

Kód: [Vybrat]

Document doc = XmlDocument.loadFrom(xmlFile)

[Reklama]

[Kit]

A mne by se libilo:

Kód: [Vybrat]

Document doc = XmlDocument.loadFrom(xmlFile)

Mně zase:

Kód: [Vybrat]

Document doc = new XmlDocument(xmlFile);

[anonym]

A mne by se libilo:

Kód: [Vybrat]

Document doc = XmlDocument.loadFrom(xmlFile)

Mně zase:

Kód: [Vybrat]

Document doc = new XmlDocument(xmlFile);

Jestli se ti to líbí, tak to ti dám radu: vyhni se Javě obloukem.

[BoneFlute]

Tak DOPRČIC, přece nebudeš mít v konstruktoru třídy parametr BufferedWriter jenom proto, abys to potom mohl otestovat? To je úplná kravina, porušuje to zapouzdřenost, vystavuješ ven vnitřnosti třídy. Prostě uděláš to, že bufferedWriter reflexí namockuješ!

Jak to vyřešíš, je druhořadé. Jednotkové testování samo o sobě vede k tomu, že ti pomáhá s dobrým návrhem kódu.

Proč je reflexe nesmysl si dobře uvědomíš v okamžiku, kdy si uvědomíš, že testováním testuješ případy užití té třídy (a správné chování v nich). Případ užití pro reflexi nějakých interních atributů (jak můžeš v jedné větě s reflexí zmiňovat zapouzdřenost?!) není, tudíž ho ani netestuješ.

[anonym]

Tak DOPRČIC, přece nebudeš mít v konstruktoru třídy parametr BufferedWriter jenom proto, abys to potom mohl otestovat? To je úplná kravina, porušuje to zapouzdřenost, vystavuješ ven vnitřnosti třídy. Prostě uděláš to, že bufferedWriter reflexí namockuješ!

Jak to vyřešíš, je druhořadé. Jednotkové testování samo o sobě vede k tomu, že ti pomáhá s dobrým návrhem kódu.

Proč je reflexe nesmysl si dobře uvědomíš v okamžiku, kdy si uvědomíš, že testováním testuješ případy užití té třídy (a správné chování v nich). Případ užití pro reflexi nějakých interních atributů (jak můžeš v jedné větě s reflexí zmiňovat zapouzdřenost?!) není, tudíž ho ani netestuješ.

Moje poslední reakce na tebe v tomhle vláknu, protože to nemá smysl. Integrační testy testují pípady užití té třídy, ne Unit testy! Unit testy, o kterých je tu řeč, testují metody té třídy izolovaně od okolí, pitvají tu třídu! Člověk, se kterým má smysl na tohle vést řeč, by to měl vědět.

[BoneFlute]

1. Třeba tohle je přesně ten shit, který nechci dělat:

Kód: [Vybrat]

	DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
	DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
	Document doc = dBuilder.parse(xmlFile);

2. Proč, když to jde takhle jednoduše:

Kód: [Vybrat]

	XmlDocument doc = new XmlDocument();  
        doc.LoadXml(xmlFile);  

A že není 2 tak obecná? Dpč, 99,5% případů užití je jen pro ten příklad č. 2!

A co na tom nechceš dělat? Ty příklady jsou zcela zaměnitelný, použij co ti přijde hezčí. Neřeší to nic z toho, co popisuješ.

Případ, kdy objekt zpracovává soubor:

Kód: [Vybrat]

class A:
    private DocumentBuilder parser
    constructor():
         DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
         this.parser = dbFactory.newDocumentBuilder();

    parse(file):
         doc = this.parser.parse(file)
         -- další logika, kdy zpracovávám doc

Případ, kdy soubor konfiguruje objekt:

Kód: [Vybrat]

class B:
    private config
    constructor(configfile):
         DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
         parser = dbFactory.newDocumentBuilder();
         doc = parser.parse(configfile)
         this.config = unifiq(doc)

    foo(data):
         -- další logika, kdy zpracovávám config

[BoneFlute]

Integrační testy testují pípady užití té třídy, ne Unit testy! Unit testy, o kterých je tu řeč, testují metody té třídy izolovaně od okolí, pitvají tu třídu!

Jednotkové testy testují jednotku. Pitvavé testy pitvají třídu.
Integrační testy testují integraci třídy do systému. Proto se jmenují integrační.
Netřeba v tom hledat nějakou složitost. Prostě jen se drž názvosloví a nevymejšlej blbosti.

Člověk, se kterým má smysl na tohle vést řeč, by to měl vědět.

Jsi si jist, že máš na to posuzovat znalosti někoho jiného? Vzhledem k tomu, co tu uvádíš za bludy?

Slovy klasika, že nezkušení jsou si tak jistí, a zkušení plni pochybností.

Přeji ti hodně štěstí, už se nebudu obtěžovat ti něco vysvětlovat.

[BoneFlute]

Unit testy - testuji jednotku. tudiz vnitrni implementaci a strukturu testovaneho objektu.
Casto se to plete dohromady.
https://www.lucassaldanha.com/unit-tests-vs-acceptance-tests/

Testují chování implementaci vůči veřejnému rozhraní. Testují, zda se to chová jak bylo domluveno. Ale netestují žádné privátní fieldy, protože to jaksi není veřejné rozhraní, a jaksi to ani nikdy nepoužiješ. Vývojář to kdykoliv může přepsat, privátní fieldy zahodit, privátní pomocné metody sloučit, rozdělit, nebo přepsat, a testy musí stále projít. Protože se nezměnilo chování ale pouze implementace. Od toho ty testy jsou.

Testovat implementaci pro implementaci jaksi nemá smysl, že jo.

Ostatně ten článek neříká nic o tom, že by se mělo testovat privátní fieldy, nebo pitvat třídu, jak si to tu anonym představoval.

[Kit]

A mne by se libilo:

Kód: [Vybrat]

Document doc = XmlDocument.loadFrom(xmlFile)

Mně zase:

Kód: [Vybrat]

Document doc = new XmlDocument(xmlFile);

Jestli se ti to líbí, tak to ti dám radu: vyhni se Javě obloukem.

Proč?

[anonym]

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

[listoper]

Unit testy - testuji jednotku. tudiz vnitrni implementaci a strukturu testovaneho objektu.
Casto se to plete dohromady.
https://www.lucassaldanha.com/unit-tests-vs-acceptance-tests/

Testují chování implementaci vůči veřejnému rozhraní. Testují, zda se to chová jak bylo domluveno. Ale netestují žádné privátní fieldy, protože to jaksi není veřejné rozhraní, a jaksi to ani nikdy nepoužiješ. Vývojář to kdykoliv může přepsat, privátní fieldy zahodit, privátní pomocné metody sloučit, rozdělit, nebo přepsat, a testy musí stále projít. Protože se nezměnilo chování ale pouze implementace. Od toho ty testy jsou.

Testovat implementaci pro implementaci jaksi nemá smysl, že jo.

Ostatně ten článek neříká nic o tom, že by se mělo testovat privátní fieldy, nebo pitvat třídu, jak si to tu anonym představoval.

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