[Alg] Methode gezocht om dependancies in kaart te brengen*

[Verwijderd]

Om te beginnen, ik ben geen programmeur. Wel test ik regelmatig software. Nu heb ik de volgende vraag.

Het gebeurd regelmatig dat programmeurs ergens in een applicatie code aanpassen en dat daarmee onverwacht ergens anders in de applicatie niet meer werkt zoals zou moeten. Dit is van te voren erg lastig te bapelen en dus te testen.
Is het mogelijk om in bijvoorbeeld C# (,NET 2.0) zo proggrammeren dat te zien is op welke delen van de applicatie het aanpassen van een stuk code invloed heeft? Ik zou bijvoorbeeld graag willen weten wanneer een methode, functie, klasse etc....wordt aangepast, welke andere applicatieonderdelen gebruik hiervan maken en waar het dus invloed op heeft. Als ik dit weet kan dit weer worden gekoppeld aan een scherm, zodat deze extra getest kan worden.

Ik heb zelf gezocht op google maar ik ben niet bekend met de termen hiervoor dus vind ik niet ik wat ik wil vinden.

Bestaan er zulke methoden als ik bedoel? Zo ja wat zijn de naam hiervoor.

[joopst]

Het is een interessant probleem ik ben zelf ook bezig om te kijken hoe je nou dusdanig tests kan opzetten zodat je naast de happy-path alle variaties kan testen, zonder te verzanden in oeverloos en eindeloos geklik.
Volgens mij zit er een groot deel van de oplossing in de architectuur van de app.

In ieder geval, als je weet welke method er aangepast is, kan je met de reflector kijken vanaf waar deze wordt aangeroepen.

Verders heb ik er een boek over besteld bij amazon. Volgens de reviews is ie wel aardig.

Mocht je zelf al een c00l boek hierover hebben dan zou ik het ook wel willen weten

[TeeDee]

Kan je hier niks mee?

Edit, ooo, je wil nog meer. Dan houdt het met dependency walker ook op afaik.

[ Voor 39% gewijzigd door TeeDee op 17-03-2006 16:58 ]

[[ti]]

Schrijven de programmeurs unit tests bij hun code?

[Varienaja]

[ti] schreef op vrijdag 17 maart 2006 @ 18:26:
Schrijven de programmeurs unit tests bij hun code?

Precies. Gewoon bij het inchecken van de nieuwe code de unittests uitvoeren, en de code pas toelaten als alle tests met goed gevolg worden afgelegd.


_{* Varienaja wou dat wij op het werk zo'n systeem hadden...}

[ Voor 6% gewijzigd door Varienaja op 17-03-2006 19:08 ]

[Verwijderd]

[ti] schreef op vrijdag 17 maart 2006 @ 18:26:
Schrijven de programmeurs unit tests bij hun code?

Dit durf ik niet met zekerheid te zeggen maar ik denk het niet. Ik zal dit maandag meteen even vragen aan een collega. Indien dit niet het geval is, zal ik een balletje op gooien om dit wel te laten gebeuren. Er wordt nog niet echt ontwikkeld dus er is nog niets aan de hand..:)

Ik ben van mening dat een unit test eigenlijk een verplicht onderdeel moet worden van het werk van de programmeur. Dit leidt alleen maar tot goede code en software hoeft niet teruggestuurd te worden naar een ontwikkelaar wanneer er code fouten blijken te zijn.Want dat is toch het doel van een unit test?

Echter met een unit test weet men volgens mij nog niet of een andere onderdeel wat bijvoorbeeld gebruikt maakt van een applicatie nog wel werkt. Want in de unit test wordt de methode zelf alleen gecheckt.

Wat ik dus zoek is informatie over een methode van programmaeren waarmee het volgende bereikt kan worden: het moet duidelijk zijn welke andere applicatie onderdelen gebruik maken van een gewijzigde methode bijvoorbeeld of een andere code onderdeel.
Wanneer dit beken is zou er bijvoorbeeld, als dit mogelijk is, een soort van code afhankelijkheidst test kunnen worden gebouwd. Een soort van regressietest in de code!

Als dit al bereikt kan worden voordat het naar een test afdeling gaat dan kan er volgens mij al snel software worden getest wat meteen al behoorlijk goed is.
Wanneer de afhankelijkheden ook nog eens vertaald kunnen worden naar schermniveau en dus naar werkprocessen dan kan er op een testafeling een zo smal mogelijk regressietest worden gemaakt op werkproces niveau. Immers, in de regressietest wil je het lieft zo min mogelijk testen op een blijvende juiste werking.

Ik heb dus een leuk idee en ik wil weten of hier methoden voor bestaan. Uiteindelijk wordt de software er beter van en wordt er veel tijd bespaard.

p.s. er zal worden gewerkt met C# op het .NET 2.0 framework. Hierbovenop is men nu bezig met schrijven van een eigen framework dus als bovenstaande mogelijk is dan zou dit hierin verweven kunnen worden.

p.s. 2: bedankt voor de aanpassing voor de topic titel, ik wist even niet hoe ik duidelijk dit topic moest beschrijven..

[ Voor 8% gewijzigd door Verwijderd op 18-03-2006 17:00 ]

[Verwijderd]

Ik had wel wat meer reacties verwacht, zeker omdat dit een onderwerp is wat de bezoekers van ditsubforum zeker zullen herkennen. Dus nogmaals de vraag, bestaan hier al ontwikkelde methodes voor?

[bigbeng]

Een redelijk grote naam op het gebied van refactoring en adaptable design is Martin Fowler. Misschien dat je via zijn website wat interessante info kunt vinden:
http://www.martinfowler.com/

Zijn insteek is overigens om de afhankelijkheden tussen diverse objecten te minimaliseren en om de pijn van aanpassingen te verzachten, dus niet helemaal wat jij bedoelt.

[Janoz]

Verwijderd schreef op zaterdag 18 maart 2006 @ 16:56:
Ik ben van mening dat een unit test eigenlijk een verplicht onderdeel moet worden van het werk van de programmeur. Dit leidt alleen maar tot goede code en software hoeft niet teruggestuurd te worden naar een ontwikkelaar wanneer er code fouten blijken te zijn.Want dat is toch het doel van een unit test?

Echter met een unit test weet men volgens mij nog niet of een andere onderdeel wat bijvoorbeeld gebruikt maakt van een applicatie nog wel werkt. Want in de unit test wordt de methode zelf alleen gecheckt.

Wanneer je goede unit tests schrijft worden ook dit soort dingen gecontroleerd. Daarnaast zou het gebruikelijk moeten zijn om niet alleen de test van het stukje aangepaste code, maar juist alles unit tests te draaien. Aangezien dit toch een automatisch proces is kan dit gewoon in je build proces opgenomen worden.

Door ale onderdelen van je applicatie te testen zou naar voren moeten komen dat een verborgen afhankelijkheid niet meer werkt.

[Verwijderd]

Janoz schreef op woensdag 22 maart 2006 @ 10:23:
[...]

Wanneer je goede unit tests schrijft worden ook dit soort dingen gecontroleerd. Daarnaast zou het gebruikelijk moeten zijn om niet alleen de test van het stukje aangepaste code, maar juist alles unit tests te draaien. Aangezien dit toch een automatisch proces is kan dit gewoon in je build proces opgenomen worden.

Door ale onderdelen van je applicatie te testen zou naar voren moeten komen dat een verborgen afhankelijkheid niet meer werkt.

Met het laatste ben ik het enigzins eens, wanneer je een hele applicatie test dan zullen de fouten inderdaad vanzelf naar voren komen. Is dit in de praktijk haalbaar? Stel men bouwt aan een uitgebreid crm pakket, kost het dan niet erg veel tijd om voor een aanpassing de hele applicatie te gaan uni testen? Hier schiet mij technische kennis te kort om daarover wat te zeggen... Als dit een kwestie van een paar minuten is dan is het niet erg maar ik verwacht dat alles unit testen wel wat langer duurt? Zie ik iets verkeerd ?

[kenneth]

Ja dat kost tijd. Ongeveer tien keer zo weinig als obscure bugs opsporen

En natuurlijk kan je de boel automatiseren zodat het 's nachts wordt gedraaid, dan kan je eventuele probleem in ieder geval isoleren tot de commits van die dag.

[Janoz]

Verwijderd schreef op woensdag 22 maart 2006 @ 16:23:
[...]


Met het laatste ben ik het enigzins eens, wanneer je een hele applicatie test dan zullen de fouten inderdaad vanzelf naar voren komen. Is dit in de praktijk haalbaar? Stel men bouwt aan een uitgebreid crm pakket, kost het dan niet erg veel tijd om voor een aanpassing de hele applicatie te gaan uni testen? Hier schiet mij technische kennis te kort om daarover wat te zeggen... Als dit een kwestie van een paar minuten is dan is het niet erg maar ik verwacht dat alles unit testen wel wat langer duurt? Zie ik iets verkeerd ?

Het unit testen is een automatisch proces. Je start het op en het gaat de hele applicatie afratelen. Met verschillende build tools (make, ant, maven, enz. Geen idee hoe ze bij .net heten) kun je het onderdeel maken van het 'build distribution' target. Hoe lang de tests duren is geheel afhankelijk van hoe veel tests en hoe zwaar ze zijn, maar omdat het een automatisch proces is hoef je het niet te monitoren. Je kunt rustig met andere dingen bezig en zodra het klaar is het test rapport doornemen of enkel kijken of er 0 fouten zijn geweest.