SWT - Design for Testability

Question 1

Hvad forståes ved en komponents dependencies/afhængigheder?

Answer 1

En komponent (f.eks. en klasse) indgår ofte som en del af et større system, hvor den interagerer med andre dele af systemet. Disse andre dele, som klassen interagerer med, kaldes for klassen dependencies/afhængigheder.

Question 2

Hvad skal vi være opmærksomme på, hvis vi tester nedenstående klasse A?

Answer 2

At methodA() kalder videre til klasse B, så hvis testen fejler, ved vi ikke om fejlen opstår i klasse A eller klasse B.

Derfor er vi nødt til at afkoble den klasse, som vi tester, fra resten af systemet.

Question 3

Hvad er Comple Test vs. Robust Tests en balancegang imellem?

Answer 3

• Hvis vi ved hvad der er indeni vores unit, kan vi bedre teste det
• Hvis vi kan kigge indeni vores unit, kan vi lavere mere komplette tests

VS

• Hvis vi baserer vores tests på hvad der er indeni vores unit, kan testen breake når vores kode ændres/vedligeholdes

Question 4

Hvad er Black Box testing?

Answer 4

En måde at teste funktionalitet/behavior på, når vi ikke kender til hvad der foregår indeni i den kode (unit) som vi skal teste. Dvs. vi ser kun på hvad der sker i overfladen af ‘den sorte box’ og hvad der sker udadtil.

Question 5

Hvad er White Box testing?

Question 6

Hvordan kan man lave en Black Box test?

Answer 6

• ACT:
  
  • Give et input/act’e (f.eks. at forsøge at kalde noget på den) og så observere på outputtet (f.eks. om den kalder videre i systemet eller noget andet)
• INTERACT:
  
  • Kalder noget på den, som giver en returværdi, som vi så observerer på
• REACT:
  
  • Kalder noget på den, som kalder ivdere i systemet og så giver returværdi tilbage til vores objekt (uut), som vi så observerer på

Question 7

Hvornår ved vi generalt at en Black Box test er sikker/fungerer fornuftigt?

Answer 7

Så længe vi kun bruger den kontrakt, som vi har opsat for vores enhed, kan vi være sikre på at vores tests fungerer fornuftigt.

Med andre ord: Så længe interfacet for uut og interfacet for den testede kode er det samme, er vores tests sikre.

Question 8

Vil vi helst have Whitebox eller Blackbox tests?

Answer 8

Blackbox tests, da de er lettere at automatisere og testen kan lettere breake ved Whitebox testing, når vi maintainer eller ændre i vores kode senere hen (som vi hele tiden gør som udviklere)

Question 9

Hvad afgører om vi skal bruge Blackbox eller Whitebox testing?

Answer 9

Hvor meget information vi har om den komponent som vi tester. Vi kan ikke lave Whitebox test, hvis vi ikke kender til hvad der sker indeni koden. I praksis vil vi i kurset helst bruge Blackbox tests.

Question 10

Vi ønsker at teste funktionaliteten af en klasse. Hvad skal vi gøre først, hvis klassen har dependencies?

Answer 10

Først skal vi afkoble klassen fra resten af systemet som det intereagerer med. På denne måde kan vi kontrollere hvilke dependencies som UUT bruger, f.eks. vores “fake” version af afhængighederne

Question 11

Hvad vil det sige at vi kontrollere UUT’s dependencies?

Answer 11

At vi kontrollere hvilke afhængigheder som UUT bruger, f.eks. fake dependencies eller rigtige dependencies.

Question 12

Hvordan kan vi kontrollere typerne af en UUT’s dependencies?

Answer 12

Ved at injecte (vores fake) dependencies ind i UUT, fremfor at klassen selv konstruere det.

På denne måde kan vi isolere UUT fra resten af systemet.

Question 13

Hvilke steps ligger der i kontrol af dependencies (III eller Triple-I)?

Answer 13

1. IDENTIFY: Identificér de eksterne dependencies
2. INTERFACE: Introducer et interface til afhængigheden
3. INJECT: Erstat (inject) afhængigheden

Question 14

Hvad kendetegner et interface?

Answer 14

• Kan ikke indeholde fields (variabler)
• Kan kun indeholde function declarations, men funktionernerne defineres kun af de klasser, der implementerer interfacet
• Funktionerne skal erklæres public, når de implementeres i klasserne, der implementerer interfacet

Question 15

Hvordan kan vi løsne koblingen imellem en klasse og dens dependencies?

Answer 15

Ved at introducere et interface til afhængighederne.

Question 16

Vi skal introducere et interface til afhængigheden Bedroom. Hvad vil House egentlig have at gøre med Bedroom?

Answer 16

“Kalde TurnLightOff() på sit Bedroom-objektet”

eller

“Slukke lyset i Bedroom” (korrekt)

Question 17

Hvordan bruges “constructor injection” på dette eksempel?

Answer 17

Få klassen til at anvende interfaces som dens afhængigheder, så den er ligeglad med den konkrete type.

Så fremfor at klassen selv konstruere sine afhængigheder, kan vi injecte hhv. vores fake dependencies eller rigtige dependencies i constructoren for både Produktion og Test-klassen:

Question 18

Hvordan bruges “property injection” på dette eksempel?

Answer 18

Få klassen til at anvende properties, der sættes i dens constructor, hvor dens dependencies initailiseres.

Disse properties overskrives i Test-klassen, hvor vi injecter vores fake properties.

Question 19

Hvad kan være et problem ved “property injection”?

Answer 19

At hvis klassen (som vi tester) selv opretter dens dependencies i sin constructor, kan de udføre ting, der ikke kan tilbageføres, selvom vi overskriver dependencies i Test-klassen

Dvs. at vi ikke kan være sikre på vores UUT’s tilstand, når vi tester

Question 20

Nævn nogle design principper og mønstre for Design for Testability

Answer 20

• Lav kobling:
  
  • Triple-I (design med interfaces)
  • Brug Observer Pattern (i C# oftest gjort med events og delegates)
  • Brug Exceptions (men ikke for normal returnering af data)
• Single responsibility:
  
  • Reducerer antallet af interne tilstande
  • Gør koden mere simpel
  • Gør det mere simpelt at teste
  • Refactor (brug testene for at sikre at du har gjort det rigtigt)

Question 21

Hvis det er svært at skrive tests, hvad kan det så være symptom på?

Answer 21

• At designet muligvis er dårligt
• At det måske er svært at bruge den unit
  
  • Husk at testen er den første client - hvad med faktiske final client (andre færdige klasser og komponenter)