SWT - Fakes Flashcards
Hvad er en “fake”?
En falsk version af en af klassens afhængigheder
Hvorfor bruger vi fakes?
For at isolere UUT fra resten af systemet, for at vi kan teste vores unit isoleret og have kontrol over klassens afhængigheder.
Hvordan muliggør vi at bruge fakes i vores tests?
Hvis designet ikke allerede er til det, bruger vi Triple-I (identify, interface, inject) til at isolere klassen fra dens afhængigheder, så vi kan styre testen.
Vi laver altså en loose coupling på designet.
Hvilke to store grupper af unit tests findes der?
- Value based eller state based tests, hvor man ser på om en unit returnerer den forventede værdi eller er i den forventede (eksterne*) tilstand, når vi har acted på den.
- Behaviour based eller interaction based tests, hvor man ser på om en unit har den forventede opførsel overfor sine dependencies, når vi har beder dem om at gøre noget.
*eksterne: som det er meningen, vi kan observe på “udefra”
Hvilken type af fakes har vi brug for i en value/state-based unit test?
Vi har brug for stubs, så vi selv kan kontrollere hvad vores fake dependency sender retur til UUT (se “fakes-stubs_example01.PNG”)
Hvad bruges stubs til i en value/state-based unit tests?
Stubs fungerer som vores UUT’s fake dependencies og/eller give UUT en kontrolleret værdi som den har brug for til at fungere (f.eks. bare være til stede eller returnere en værdi til UUT)
- (se “fakes-stubs_example01.PNG”)
Hvad er proceduren for value/state based unit tests?
Den sædvanlige:
- ARRANGE: opsæt UUT og dens fake dependencies
- ACT: stimuler UUT
- ASSERT: se om UUT er i den forventede tilstand eller returnerer den forventede værdi
Hvad asserter vi på, når vi laver en value/state-based unit tests, hvor vi anvender fakes?
Vi asserter på at UUT er i den forventede tilstand eller returnerer den forventede værdi.
Hvilken type af fakes har vi brug for i en interaction/behaviour-based unit test?
- Mocks, da vi gerne vil “optage” den opførsel der skete, for at teste om UUT’s opførsel overfor dens dependencies stemmer overens med hvad vi forventede.
- Muligvis stubs til at give UUT enhver anden dependency, den har brug for for at fungere (f.eks. en værdi eller bare at være til stede).
Hvad bruges mocks til i en interaction/behaviour-based unit tests?
Mocks bruges til at “optage” den interaktion/opførsel som der sker med UUT, fordi vi gerne vil teste om UUT har den forventede opførsel med sine dependencies.
Hvad bruges stubs til i en interaction/behaviour-based unit tests?
Stubs bruges til at give UUT enhver anden dependency, den har brug for for at fungere (f.eks. en værdi eller bare at være til stede)
- Stubs er ikke altid nødvendigt i en behaviour-based unit test
Hvad er proceduren for interaction/behaviour based unit tests?
Den sædvanlige:
- ARRANGE: opsæt UUT og dens fake dependencies
- ACT: stimuler UUT
- ASSERT: se om vores mock modtog den forventede interaktion/opførsel med UUT
Hvad asserter vi på, når vi laver interaction/behaviour-based unit tests?
Vi asserter på at vores mocks modtog (“optog”) den forventede interaction med UUT.
Kan vores fake være skyld i at testen fejler i en value/state-based unit test?
Nej, vores fake kan aldrig være skyld i fejlen, da vi asserter på UUT og aldrig på vores stub.
Kan vores fake være skyld i at testen fejler i en interaction/behaviour-based unit test?
Ja, det er muligt at vores fake er skyld i fejlen, da det vi asserter på vores mock.
Hvad gør NSubstitute for os her?
Laver fake klasser, der implementer hhv. IHeater og ITempSensor interfacene.
Så behøver vi ikke selv at skrive manuelle fake klasser.
Hvad gør vi her og hvilken type unit test er det?
En interaktion/behaviour based test.
Vi asserter på at vores mock _heater modtog præcist ét kald til TurnOn(). Redieved() er her en implicit “asserter”
