Archief - software testing (C#)

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
c

crazyman2

Legacy Member
Ik ben op zoek naar goede bronnen voor zowel een overzicht voor testen van OO software + wat meer diepgang in die onderwerpen.

Ik heb al eens rondgezocht, maar ik vind geen goeie inleiding tot het testen van software :( Het is of wel te vaag, ofwel veel te ingewikkeld voor een beginner. Daarom vroeg ik me af of iemand me een goed boek/bron kan aanraden om te starten.
c

crazyman2

Legacy Member
Mixana zei:
Bedoelt ge iets gelijk Test Driven Development?
Amazon.com: The Art of Unit Testing: With Examples in .Net (9781933988276): Roy Osherove: Books

Anders google maar op Test Driven Development.
Klik om te vergroten...
TDD is te nauw, dat is vooral vanaf het begin met unit tests. Kmoet vooral een overzicht van de verschillende testmethodes hebben zoals unit tests, integration tests, system tests etc ...

Wel een goed boek (al gelezen namelijk) :D

@Fraggie
Kga dat zeker eens bekijken, lijkt wel interessant en in de trend van wat ik moet hebben, bedankt :applause:
c

crazyman2

Legacy Member
Bon, kheb nu dat boek doorgelezen.

Toch nog een paar vragen:
Hoe onderscheid integration testing zich nu exact van unit testing? Want zelfs de meeste relatief kleine klassen gaan nog afhankelijk zijn van andere klasse (die je mogelijk kan wegstubben).

Misschien even een concreet voorbeeld geven:
Programma berekent iets en stuurt dit weg naar een bestand.
Unit testing zou dan zijn: Een (publieke) methode uit de rekenklasse die een berekening maakt en het testen van een methode uit de klasse die het bestand wegschrijft en controleert met een mock of het bestand wordt weggeschreven.

Integration testing:
Bovenstaande 2 modules laten samenwerken, en dan controleren of het bestand wordt aangemaakt, en effectief controleren of het bestand bestaat?

Daarnaast: Valt het effectief uitproberen van de software onder Bigbang integration testing, of meer onder system testing?
f

forloRn_

Legacy Member
crazyman2 zei:
Toch nog een paar vragen:
Hoe onderscheid integration testing zich nu exact van unit testing? Want zelfs de meeste relatief kleine klassen gaan nog afhankelijk zijn van andere klasse (die je mogelijk kan wegstubben).
Klik om te vergroten...

Dat is het hem net. Je streeft naar klassen die niet afhankelijk zijn van andere klassen (noch van het netwerk, het file system of nog iets anders), zodat je deze klassen geïsoleerd kunt unit testen. Je zorgt ervoor dat je programmeert tegen een interface in plaats van tegen een concrete klasse, en bij het unit testen geef je dan mock-implementaties als dependencies.

crazyman2 zei:
Misschien even een concreet voorbeeld geven:
Programma berekent iets en stuurt dit weg naar een bestand.
Unit testing zou dan zijn: Een (publieke) methode uit de rekenklasse die een berekening maakt en het testen van een methode uit de klasse die het bestand wegschrijft en controleert met een mock of het bestand wordt weggeschreven.
Klik om te vergroten...

Die method in de rekenklasse geeft een resultaat terug dus het enige wat je moet doen is dat resultaat controleren.

Wat het bestand wegschrijven betreft: je zit hier met een dependency op het file system dus wat je kunt doen is alles wat effectief interageert met het file system achter een interface stoppen, genre:
Code: 
public interface FileSystem {
    void create(File file);
    void write(File file, String s);
    void delete(File file);
    // ...
}

Bij het unit testen maak je dan weer een mock-implementatie die gewoon de parameters van die methods controleert en klaar.
f

forloRn_

Legacy Member
Wel, op het eerste zicht niet eigenlijk. Maar trek vooral uw plan met uw huiswerk.
c

crazyman2

Legacy Member
Snel op de tenen getrapt? :D

En nu serieus, ik weet genoeg over unit testing, je stubt de dependencies weg, en je mockt de call voor het wegschrijven van het bestand. Je herhaalt eigenlijk gewoon wat ik zei. Toch bedankt.

Tis gewoon de onduidelijkheid tussen unit test en integration test. Unit test is klein, alle dependencies weggestubt. Snel uit te voeren, 1 ding controleren etc. . Is integration testing dan gewoon effectief berekenen en een bestand uitschrijven en dan controleren of de file aangemaakt is? Ik vraag me dan af of het niet gewoon beter is dit handmatig te controleren (voor een klein project uiteraard). Is dit dan Big Bang intergration testing?
M

Moto

Legacy Member
effe verduidelijken

handmatig controleren Eens er een UI is is dit een ESSENTIEEL onderdeel van het schrijven van deftige software, ge moet dat niet in een vakske proberen steken, met de Hand testen is iets dat MOET gebeuren, en dat zeker niet door unit/integration tests verminderd kan worden.

En als ge dan zoiets hebt van "Jamma, jamma handmatig controleren is niet leuk" wilt dat meestal zeggen dat uw software niet leuk is :p
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan