[alg/oo]testen van private methods duidt op slecht ontwerp?

[JeroenTheStig]

How do I test private methods?

Testing private methods may be an indication that those methods should be moved into another class to promote reusability.

Aldus de JUnit faq.

Ik vraag me al een tijdje af op welke manier ik het beste m'n private methoden kan testen. Als het goed is, worden private methodes indirect meegetest wanneer alle public methodes van een klasse worden getest met behulp van unit tests (de zogenaamde black-box test).

Bij complexe private methoden zou je ze het liefst apart willen testen, maar helaas gaat dat niet. Volgens de JUnit faq's zou je complexe private methoden moeten verplaatsen naar andere klasses om hergebruik te bevorderen. Ook ben je direct van je probleem af dat de methoden niet apart te testen zijn.

Ik zou graag een discussie willen zien hoe andere mensen denken over de stelling dat testen van private methoden duidt op een slecht ontwerp. Ook ben ik benieuwd hoe je dit eventueel wilt oplossen qua ontwerp (static tool-classes, enz.).

[Robtimus]

Ik ben het niet met JUnit eens.

Stel je voor, je hebt 2 public methods, met allebei een eigen verschillend stuk code en een groot, complex gedeeld stuk code. Dat gedeelde stuk stop je dan in een private method. Reden: het is implementatie specifiek, dus geen andere class zou er toegang toe mogen krijgen. Waar is private anders voor?
Dat de gedeelde private method complex is verandert daar IMHO niks aan.

[Verwijderd]

Een complexe private methode kan worden omgezet in een klasse via het strategy-patroon, hopelijk zelfs fly-weight.
De strategy kan getest worden omdat deze nu public is.
Door met fly-weights te werken wordt afgedwongen dan de klasse geen interne variabelen kent en is de hele toestand waaronder de strategy draait extern op te leggen.

[Alarmnummer]

Verwijderd schreef op 17 september 2004 @ 16:04:
Een complexe private methode kan worden omgezet in een klasse via het strategy-patroon, hopelijk zelfs fly-weight.
De strategy kan getest worden omdat deze nu public is.
Door met fly-weights te werken wordt afgedwongen dan de klasse geen interne variabelen kent en is de hele toestand waaronder de strategy draait extern op te leggen.

Yeah... en een simpel ontwerp ingewikkeld maken.

hopelijk zelfs fly-weight.

Hmmm.. ik zie de relatie tussen een flyweight en een strategy/private methode niet.

Oplossing trouwens om private methodes te testen is om ze package friendly te maken (dus geen access modifier ervoor). Ik weet dat dit niet helemaal lekker is, maar de protected access modifier heeft deze 'lek' ook, en dat gaat ook al jaren goed.

[ Voor 31% gewijzigd door Alarmnummer op 17-09-2004 16:24 ]

[JeroenTheStig]

Alarmnummer schreef op 17 september 2004 @ 16:11:
Oplossing trouwens om private methodes te testen is om ze package friendly te maken (dus geen access modifier ervoor). Ik weet dat dit niet helemaal lekker is, maar de protected access modifier heeft deze 'lek' ook, en dat gaat ook al jaren goed.

Dat betekent dus dat je unit test classes in dezelfde package geplaatst moet worden?

btw, wat is fly-weight ?

[ Voor 5% gewijzigd door JeroenTheStig op 17-09-2004 16:32 ]

[Alarmnummer]

Boktor schreef op 17 september 2004 @ 16:31:
[...]


Dat betekent dus dat je unit test classes in dezelfde package geplaatst moet worden?

Yep.. maar daar is wel een hele strakke oplossing voor.

src/core/foo/bar/Snotje.java
src/core-test/foo/bar/SnotjeTestSuite.java


Je maakt dus 2 directories aan: core en core-test.

En de classes:
foo.bar.Snotje
foo.bar.SnotjeTestSuite
zitten wel in dezelfde package.

btw, wat is fly-weight ?

Stel dat je voor een editor iedere character gaat maken als een object. Dit werkt op zich erg prettig omdat je er gewoon methode calls op kan doen. Alleen is dit wel extreem kostbaar.

De flyweight is hiervoor een oplossing. Je maakt dan wel een object aan, maar dat object weet niet de context waarin hij gebruikt wordt (de letter a kan op 1 pagina wel 1000 keer gebruikt worden), maar toch maak je maar 1 object hiervoor aan die iedereen mag gebruiken.

Op het moment dat je alles gaat tekenen, dan moet je wel de context (bv de xy locatie of de parent line ) mee gaan geven.

[ Voor 16% gewijzigd door Alarmnummer op 17-09-2004 16:41 ]

[Verwijderd]

Het gaat om een ingewikkelde private method. Goed werken hiervan is dus belangrijk maar tegelijk is de methode moeilijk te testen. "Moeilijk" ontwerp kan testen makkelijker maken.

Fly-weight is een type klasse waarbij de interne status geen relatie heeft met de omgeving van het object. De lol hiervan is dat objectenen van deze klasse gepoold kunnen worden, zie het voorbeeld van Alarmnummer. Ook is wisselen tussen test- en productieobject makkelijk. Vanuit de gebruikende klasse gezien: de Fly-weight kan per direct gedumpt of gewisseld kan worden.

Nu strategy. Bot geformuleerd is Strategy is een tot klasse gepromoveerde method. Het method-karakter (status-loos) van Strategy maakt Strategy tot goeie Fly-weight kandidaat. Strategy is een klasse en kan wel status hebben, bv in geval van een neuraal netwerk: de opbouw en africhting. Wanneer een configuratie algemeen inzetbaar blijkt, bijvoorbeeld dat het neuraal netwerk met gelijke configuratie op veel plaatsen in een programma beslissen kan, is deze Strategy ook nog Fly-weight.

Wanneer een Strategy tevens Fly-weight is en Strategy is geen friend o.i.d van de gebruikende klasse, is afgedwongen dat Strategy niet in de gebruikende klasse kan hacken. Wel vereist deze aanpak een interface ontwerp voor Strategy. De parameterisering van de methods is hierbij het lastigst: immers alle ingrepen van Strategy op de gebruiker lopen via publieke methodcalls. Maar dan is ook direct beter begrepen wat de complexe functie wel en niet kan doen.

Het patroon Strategy beschrijft een abstracte basisklasse waar concrete Strategies van afgeleid zijn: bv versie 1 en 2 van een beslissingsmethode.

[whoami]

Verwijderd schreef op 17 september 2004 @ 22:57:

Hmmm, even mierenneuken: flyweight en strategy zijn geen klassen maar design-patterns. Het zijn 'standaard oplossingen' (mind the quotes) die een aantal classes definiëren die samenwerken om een 'standaard' oplossing/architectuur te bieden voor een bepaald probleem.
Een strategy pattern gaat bv. voor bepaalde verschillende 'beslissingen' (bv. bereken prijs voor reguliere klanten en bereken prijs voor occasionele klanten die methodes in aparte classes gaan stoppen die allemaal aan dezelfde interface voldoen.
Op die manier kan je makkelijk een 'pluggable' systeem maken, en vermijd je ellenlange switch of if statements.
Meer informatie over het strategy patroon vind je in het 'Design Patterns' boek van de GoF.

[Alarmnummer]

Verwijderd schreef op 17 september 2004 @ 22:57:
Het gaat om een ingewikkelde private method. Goed werken hiervan is dus belangrijk maar tegelijk is de methode moeilijk te testen. "Moeilijk" ontwerp kan testen makkelijker maken.

Persoonlijk test ik private methods niet. Ik test het contract aan de buitenkant van de class (de public methods) en daarmee vind ik dat ik ook genoeg heb getest. Maar dat terzijde... een ontwerp aanpassen om het makkelijker testbaar te maken, en zeker om zoiets 'gecompliceerds' als een strategy toevoegen vind ik een twijfelachtige zaak. Als ik het ontwerp zie dan is het onduidelijk dat die strategy alleen voor testdoeleinden daar is en kan je op het verkeerde spoor zetten.

Strategy is een klasse en kan wel status hebben

Een erg fijne eigenschap imho van het strategy. Ik vond in het begin de strategy idd maar een onhandige functie maar het is vele malen krachtiger.

Wanneer een Strategy tevens Fly-weight is en Strategy is geen friend o.i.d van de gebruikende klasse, is afgedwongen dat Strategy niet in de gebruikende klasse kan hacken. Wel vereist deze aanpak een interface ontwerp voor Strategy. De parameterisering van de methods is hierbij het lastigst: immers alle ingrepen van Strategy op de gebruiker lopen via publieke methodcalls. Maar dan is ook direct beter begrepen wat de complexe functie wel en niet kan doen.

In negen van de 10 gevallen gaat deze oplossing meer problemen opleveren dan het oplost. Ik heb al heel wat regels geprogrammeerd en strategies zijn (over het algemeen) niet patterns die je iedere dag toepast (alhoewel je soms wel van die gekke dagen hebt). Ik zou daarom de topicstarter niet aanraden om de strategy te gaan gebruiken puur en alleen om te kunnen testen.

Het patroon Strategy beschrijft een abstracte basisklasse waar concrete Strategies van afgeleid zijn: bv versie 1 en 2 van een beslissingsmethode.

Je moet je wel (continu) afvragen of je ontwerp niet onnodige complexiteit gaat introduceren. Ik hou persoonlijk van een erg simpele aanpak... het meest simpele dat werkt.

[ Voor 3% gewijzigd door Alarmnummer op 17-09-2004 23:22 ]

[Alarmnummer]

whoami schreef op 17 september 2004 @ 23:17:
[...]
Hmmm, even mierenneuken: flyweight en strategy zijn geen klassen maar design-patterns.

*geeft whoami ff een pilsje... * niet zo miereneuken op vrijdag avond zeg

[edit]
Bloog laat duidelijk zien dat hij zijn materie beheerst.. dus ik durf de gok wel aan dat hij weet wat het verschil is tussen een pattern en een class.

[ Voor 24% gewijzigd door Alarmnummer op 17-09-2004 23:24 ]

[whoami]

Alarmnummer schreef op 17 september 2004 @ 23:21:
[...]

*geeft whoami ff een pilsje... * niet zo miereneuken op vrijdag avond zeg

Kom net van een BBQ van het werk. Heb al genoeg wijn op.

Om even ontopic te gaan: ik zou ook geen private methods gaan testen; normaliter worden deze idd door een andere method ooit opgeroepen (wat is het nut anders van die method? ).

[ Voor 27% gewijzigd door whoami op 17-09-2004 23:24 ]

[whoami]

Alarmnummer schreef op 17 september 2004 @ 23:21:
[...]


[edit]
Bloog laat duidelijk zien dat hij zijn materie beheerst.. dus ik durf de gok wel aan dat hij weet wat het verschil is tussen een pattern en een class.

Dat betwijfel ik niet; de bedoeling van mijn post was eigenlijk om het wat te verduidelijken naar Boktor toe, al betwijfel ik of m'n uitleg ook goed te bevatten is.

[Verwijderd]

Dank voor de credit. Ik ben ook dronken .

[Verwijderd]

EDIT: Neeh ik ben niet |dronken|

Ik hou complexe functie defenities met evt onderliggende complexe scope altijd private, evenzo als data members van een classe zoveel mogelijk private word gehouden door mij.

Ik test bij functies waarvan moet worden vastgesteld of ze goed werken en die complex zijn zodat ik de correcte werking niet per definitie kan overzien.

Mijn tests maak ik met een speciale class die alleen bij een bepaalde DEFINE word meegecompileerd.

#ifdef(DEBUG_PRIVATE_MEMBERS)
// test code hier
#endif

Meestal in de constructor om alle private functies afzonderlijk te testen. Hierbij houd ik me aan de regel dat een private functie zo min mogelijk afhankelijk is van de staat van de class, en indien er toch afhankelijkheid is, dan zorg ik dat de class eerst in een bepaalde staat verkeert voor ik ga testen.

Mijn mening is dus, BIJ EEN SPECIALE DEFINE bijvoorbeeld in STDAFX.H dan worden alle functies getest die ENABLED worden in de build door die DEFINE. Als uitvoer van debug resultaten gebruik ik een BESTAND bij heel veel uitvoer, of een CONSOLE.

Maak dus code die naar wens wel of niet meegecompileerd word.

En ja, ik vind testen belangrijk.

Een voorbeeld, je hebt een string: hoi|dit|is|een|test

Je moet een functie schrijven als volgt:
BOOL ParserGetArg(LPCSTR lpszDataString, UINT nArg, LPSTR lpszResult, UINT cbResult);

Dan zie je in dat je die functie wel moet testen, als lpszDataString="hoi|dit|is|een|test", en nArg=1, dan kan je als programmeur kiezen dat ie lpszResult="hoi" geeft of zerobased index "dit", afhankelijk van wat je wenst, maar je moet dan wel controleren bij een simpele string of alle nArg={0...n} valide zijn. Als je voor een kleine string goede resultaten hebt, kan je zelfs een compleet boek naar de functie sturen en verwachten dat het goed werkt.

TESTEN MOET SOMS, kan jij een functie schrijven (zonder te testen) en garanderen dat je in dit voorbeeld altijd goed resulteert? Neeh, pas als je hebt getest is het bewijs voldoende.

Ik zie dat anderen vaak aan de buitenkant van een class testen, maar ik geef zo weinig public functies dat ik alles wel intern test.

Voorbeeld is HANDLE StyleCreateDevice(HWND hEventWindow);

Ik maak dan een grafische window die met photoshop is gemaakt, in dit geval voor mijn mediacentre project. Op die grafische window zitten knopjes, faders, en ruimte voor filmpjes (RECTS...) Omdat alles styleable is, heeft het programma weinig anders te doen, dan de door de gebruiker gemaakte style te creeeren. Met 1 functiecall is de mediaspeler gemaakt.

[Window]
szImage_Background="main.bmp"

[Button]
szPresentByName=Play|Stop
Play_rcPlacement=0,0,100,15
Play_szImage_StateMouseOver=playmo.bmp
Play_szImage_StateMouseDown=playmd.bmp
Stop_rcPlacement=0,30,100,15
Stop_szImage_StateMouseOver=stopmo.bmp
Stop_szImage_StateMouseDown=stopmd.bmp

Dit is een voorbeeld van een style voor de CStyleable Device van mijn project, er zijn 2 knopjes Play en Stop

void CMediaCallbackDialog::InitDialog(......)
{
StyleCreateDevice(m_hWnd);

}
void CMediaCallbackDialog::WindowProc(UINT message, WPARAM wparam, LPARAM lparam)
{
switch(message)
{
case SCB_LBUTTONUP:
{
if(!strcmp( (char*)wparam,"Play"))
{
// play ingedrukt
}
break;
}

}

Zo kan je met een heel klein iets gewldig grote complexe windows ontwerpen met photoshop, in mijn project heb ik gekozen voor RGB(255,0,255) als transperant, dus je kan ook windows maken die niet perse vierkant zijn.

Wat je ziet is dat mijn CStyleable class device wel 100 procent goed moet werken, maar de class is te complex om zomaar te maken uti het niks, dus heb ik tijdens het maken van de CStyleable class echt zorg gemaakt om helemaal gecontroleerd en getest binnen in de class te werk te gaan.

Nu snap je misschien voorbeeld 1 , als je naar [Butons] kijkt daar onder szPresentByName=PLAY|STOP, dan zie je dat ik die 1e functie hier helemaal bovenin nodig heb.

Verder is duidelijk dat die allereerste voorbeeld functie in deze toepassing van de CStyleable class niet getest kan worden buiten de class.

[ Voor 39% gewijzigd door Verwijderd op 17-09-2004 23:53 ]

[Alarmnummer]

Verwijderd schreef op 17 september 2004 @ 23:39:
EDIT: Neeh ik ben niet |dronken|
Mijn tests maak ik met een speciale class die alleen bij een bepaalde DEFINE word meegecompileerd.

Volgens mij bedoel jij design by contract testen en dat is iets anders dan unit testen.

En als je verder geen goeie mogelijkheden krijgt vanuit de taal dan kan dbc je code zelfs een stuk onduidelijker maken doordat je minder snel kan zien dat je dus dbc code voor je neus hebt ipv normale code. Helaas is tot op heden eiffel een van de weinige talen waar het onderdeel wat van de taal.. en zo nu en dan zie je alleen wat lullige halfoplossingen terug zoals bij java en het assert statement.

[Verwijderd]

In mijn huidige werk is verkennend van karakter. Hierbij kan een methode de functionele beschrijving prima volgen maar nog steeds onbruikbaar blijken. Ik pak direct maar methoden in het algemeen, van private tot public.

Uiteindelijk zullen deze methoden worden gebruikt om te beoordelen of twee personen aan elkaar gelijk zijn. Gegevens van deze personen kunnen gebrekkig of fout zijn. Van de uitslag van een vergelijking is niet met zekerheid te zeggen wat deze zou moeten zijn; soms komt zelfs een expert er zelf niet uit. Acceptabel is een bepaald % acceptabele beslissingen bij een controle groep.

Uitslagen van diverse beoordelingsmethoden moeten met elkaar vergeleken worden door partijen die niet volledige datasets mogenhebben. Daarom dus al Fly-weight. Verder is runtime switchen van method handig. Daarom kom ik uit bij patroon Strategy, Fly-wieght strategies. Mijn vergelijkingsprocedure is welliswaar public, maar sinds ik hiermee bezig ben ben ik Strategy meer gaan waarderen. Soms een beetje over-use .

[Alarmnummer]

Verwijderd schreef op 18 september 2004 @ 00:42:
Uitslagen van diverse beoordelingsmethoden moeten met elkaar vergeleken worden door partijen die niet volledige datasets mogenhebben. Daarom dus al Fly-weight. Verder is runtime switchen van method handig. Daarom kom ik uit bij patroon Strategy, Fly-wieght strategies. Mijn vergelijkingsprocedure is welliswaar public, maar sinds ik hiermee bezig ben ben ik Strategy meer gaan waarderen. Soms een beetje over-use .

Zorg ervoor dat je overuse van patterns wel een beetje onder controle houd. Te veel patterns toepassen is ook erg vervelend. (Vooral voor de mensen die het moeten onderhouden)

Refactoring to Patterns is een boek dat hierop in gaat. Je kunt nog wel ergens een draftversie op het internet vinden.

[ Voor 3% gewijzigd door Alarmnummer op 18-09-2004 09:21 ]

[misfire]

Ik vind dat de JUnit FAQ hier zeker gelijk in heeft. Private members zijn alleen bedoeld om binnen de unit gebruikt te worden. Je moet zowieso alle public, protected en package scope members al goed testen, en als het goed raak je dan al alle mogelijkheden van je private members. Het heeft dus geen zin om private members apart te testen. Het is zelfs onderhoudsgevoeliger als je dit wel doet, want zodra je je private members gaat refactoren moet je je tests aanpassen, terwijl je geen interface wijziging hebt. Eén van de doelen van unit testen is dat het refactoren vergemakkelijkt, daarom test je op de interface van de unit, niet de implementatie.

Als je dit wel wilt is dit inderdaad een signaal dat er iets mis is met het ontwerp. Je beschouwt een private method als iets dusdanig complex dat je het eigenlijk als een aparte unit wilt testen. Dan kun je er beter ook gewoon een aparte unit van maken, en niet met inner class testing of visibility aanpassingen proberen om toch een test uit te voeren. Eén van de doelen van unit testen is om te kijken of je ontwerp goed is, dus luister naar de feedback van je tests!

Overigens noem je unit testen "black box" testing. Dat is niet correct. De termen "white box " en "black box" zeggen iets over de kennis die je gebruikt tijdens het opstellen van de test, niet zozeer het niveau waarop je de applicatie benaderd.

Unit testen vallen onder de categorie "white box" testing, omdat je als programmeur heel duidelijk weet welke dingen in je code gebeuren, en hier op anticipeert in het schrijven van de tests. Als ik code schrijf en ik vraag me af "zou dit werken?" dan ga ik hier gewoon even een speciale unit test voor schrijven. Als ik zeker weet dat een stukje code gaat werken dan zorg ik er alleen voor dat dat stukje altijd geraakt wordt, maar ga ik minder gedetailleerd testen. Op die manier bereik je een kwalitatief betere dekking dan black box, zonder dat je veel tijd besteed aan het overmatig definiëren van tests. Je krijgt snel feedback over je ontwerp ("dit is heel ingewikkeld en wil ik eigenlijk apart testen") en als je gaat refactoren worden de moeilijke dingen het beste getest.

[JeroenTheStig]

Alarmnummer schreef op 17 september 2004 @ 16:38:
[...]

Yep.. maar daar is wel een hele strakke oplossing voor.

src/core/foo/bar/Snotje.java
src/core-test/foo/bar/SnotjeTestSuite.java


Je maakt dus 2 directories aan: core en core-test.

En de classes:
foo.bar.Snotje
foo.bar.SnotjeTestSuite
zitten wel in dezelfde package.

Oh ja, dat had ik ook al wel eerder van je gezien Voor c# gaat het wat eenvoudiger, aangezien je namespaces niet in een vaste directory hoeft te bewaren.

Alarmnummer schreef op 17 september 2004 @ 23:20:
[...]

Persoonlijk test ik private methods niet. Ik test het contract aan de buitenkant van de class (de public methods) en daarmee vind ik dat ik ook genoeg heb getest. Maar dat terzijde... een ontwerp aanpassen om het makkelijker testbaar te maken, en zeker om zoiets 'gecompliceerds' als een strategy toevoegen vind ik een twijfelachtige zaak. Als ik het ontwerp zie dan is het onduidelijk dat die strategy alleen voor testdoeleinden daar is en kan je op het verkeerde spoor zetten.

Ik begrijp dat unit tests in principe alleen op het contract worden uitgevoerd, de public methodes dus, maar waar ik nog steeds niet over uit ben is hoe ingewikkelde private methodes getest moeten worden. Je kunt ze idd package safe maken, maar als ik eerlijk ben vind ik dat een niet zo'n mooie oplossing. Vooral omdat private methodes hulpmethodes zijn en niet tot het contract behoren.

In negen van de 10 gevallen gaat deze oplossing meer problemen opleveren dan het oplost. Ik heb al heel wat regels geprogrammeerd en strategies zijn (over het algemeen) niet patterns die je iedere dag toepast (alhoewel je soms wel van die gekke dagen hebt). Ik zou daarom de topicstarter niet aanraden om de strategy te gaan gebruiken puur en alleen om te kunnen testen.

Zou je private methodes ook niet willen refactoren naar een strategy om hergebruik te bevorderen? Of zou je dit op een andere manier aanpakken?

whoami schreef op 17 september 2004 @ 23:25:
[...]


Dat betwijfel ik niet; de bedoeling van mijn post was eigenlijk om het wat te verduidelijken naar Boktor toe, al betwijfel ik of m'n uitleg ook goed te bevatten is.

dankje voor de correctie (classes->patterns) Gelukkig heb ik al het één en ander geleerd over patterns, dus voor mij is het niet nieuw

misfire schreef op 18 september 2004 @ 12:14:
Overigens noem je unit testen "black box" testing. Dat is niet correct. De termen "white box " en "black box" zeggen iets over de kennis die je gebruikt tijdens het opstellen van de test, niet zozeer het niveau waarop je de applicatie benaderd.
Unit testen vallen onder de categorie "white box" testing, omdat je als programmeur heel duidelijk weet welke dingen in je code gebeuren, en hier op anticipeert in het schrijven van de tests. Als ik code schrijf en ik vraag me af "zou dit werken?" dan ga ik hier gewoon even een speciale unit test voor schrijven. Als ik zeker weet dat een stukje code gaat werken dan zorg ik er alleen voor dat dat stukje altijd geraakt wordt, maar ga ik minder gedetailleerd testen. Op die manier bereik je een kwalitatief betere dekking dan black box, zonder dat je veel tijd besteed aan het overmatig definiëren van tests. Je krijgt snel feedback over je ontwerp ("dit is heel ingewikkeld en wil ik eigenlijk apart testen") en als je gaat refactoren worden de moeilijke dingen het beste getest.

Okey Ik had begrepen dat het testen van private methods via public methods ook wel bekend stond als 'black box testing'.

[Alarmnummer]

Boktor schreef op 19 september 2004 @ 16:04:
[...]
Oh ja, dat had ik ook al wel eerder van je gezien Voor c# gaat het wat eenvoudiger, aangezien je namespaces niet in een vaste directory hoeft te bewaren.

Zou je private methodes ook niet willen refactoren naar een strategy om hergebruik te bevorderen? Of zou je dit op een andere manier aanpakken?

Wat schiet je er mee op om private methodes te gaan 'reusen'? Ze zijn meestal gebonden aan een bepaalde context dus laat ze daar ook lekker in. Ga niet onnodig dingen generiek lopen maken want dan krijg je nare code.

Okey Ik had begrepen dat het testen van private methods via public methods ook wel bekend stond als 'black box testing'.

Blackbox testing:
je houd geen rekening met de internals van een component.
Whitebox tesing:
je gaat toch stiekum een beetje aan de binnenkant van een systeem kijken.

Ik hanteer meestal geen strakke scheiding. Ik test waar ik onzeker over ben..

[JeroenTheStig]

Alarmnummer schreef op 19 september 2004 @ 17:40:
[...]

Inderdaad, raar maar waar, ik heb het ook niet verzonnen . Classes uit namespace Foo.Bar kun je zowel in directory Foo/Bar plaatsen als in directory Foo/Blaat of Foo/Bar/Blaat.

[...]

Wat schiet je er mee op om private methodes te gaan 'reusen'? Ze zijn meestal gebonden aan een bepaalde context dus laat ze daar ook lekker in. Ga niet onnodig dingen generiek lopen maken want dan krijg je nare code.

Wat ik bedoel is dat het kan voorkomen dat private methodes erg gecompliceerd kunnen worden, en wat ook de hele discussie is in dit draadje, worden deze private methods verplaatst naar andere klasses om het testen en hergebruik te bevorderen?

[ Voor 4% gewijzigd door JeroenTheStig op 19-09-2004 19:18 ]