For å konkludere

Dette er et utdrag fra Unit Testing Succinctly eBook, av Marc Clifton, gitt vennlig av Syncfusion.

Enhetstesting er også verdifull for andre formål.

Som eksempler på bruk

En av fordelene ved enhetstesting er at den skaper en stor kodebase som eksempel på hvordan du bruker koden. For eksempel koden vi så tidligere:

[Test] public void FilnavnnavnParsingTest () Dictionary alternativer = CommandLineParser.Parse ("- f foobar"); Assert.That (options.Count == 1, "Count forventes å være 1"); Assert.That (options.ContainsKey ("- f"), "Forventet alternativ '-f'"); Assert.That (alternativer ["- f"] == "foobar");

dokumenterer et forventet gyldig brukstilfelle for kommandolinjeparseren. Vurder også å skrive enhetstester, ikke bare for din egen kode, men også å gi eksempler for tredjepartsbiblioteker. (Se etterfølgende eksempler og de interessante tingene som ble avslørt om rektangelstrukturen.)

Black Box Testing

Svart boks testing antar at du ikke vet noe om internaler av klassen eller tjenesten og verifiserer sin atferd strengt fra de offentlig synlige grensesnittene. Dette er ofte nødvendig når du ikke har koden tilgjengelig. For eksempel, da vi jobbet med et plateselskap, måtte vi bruke en webtjeneste fra et myndighetsbyrå for å oppdatere poster. Ved å skrive enhetstester for webtjenesten, kunne vi bevise at dokumentasjonen som ble levert til oss, ikke resulterte i forventet oppførsel av webtjenesten.

Du kan også bruke denne teknikken også når du arbeider med kode fra ulike avdelinger. For eksempel kan databasegruppen ha sin egen, hvite boksenhetstesting; Du bør imidlertid også verifisere at utløsere og begrensninger fra et svart-boks-perspektiv er programmert riktig ved å inspisere resultatet av transaksjoner fra funksjonaliteten som er utsatt for deg.

Test dine antagelser

Enhetstesting kan være en enkel måte å sette sammen noen tester om våre forutsetninger om en API. La oss ta System.Drawing.Rectangle strukturere og teste noen tilsynelatende fornuftige forutsetninger om implementeringen.

Testkonstruksjonsforutsetninger

Det er to Rektangel konstruktører: en har Punkt og Størrelse parametre, den andre har x, y, bredde og høydeparametere. Dokumentasjonen gir ingen indikasjon på om størrelsen (bredden eller høyden) må være positiv, så la oss skrive en test for å verifisere at vi kan konstruere et rektangel med negativ bredde eller høyde:

[TestMethod] public void RectangleNegativeSizeConstructorTest () Rektangel r = nytt rektangel (0, 0, -4, -6);

Alt vi gjør her i denne testen, er å verifisere at ingen unntak kastes når vi bygger rektangelet, og det er faktisk slik:

Rektangelkonstruktortest

Test antagelser om eiendomsverdier

La oss nå teste våre antagelser om bestemte egenskaper. Egenskapene Topp, Venstre, Bunn, og Ikke sant er beskrevet som (se
http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.aspx):

Topp: Går y-koordinaten til toppkanten av denne rektangulære strukturen.

Venstre: Får x-koordinaten til venstre kant av denne rektangulære strukturen.

Bunn: Går y-koordinatet som er summen av egenskapene Y og høyde i denne rektangulære strukturen.

Høyre: Går x-koordinaten som er summen av X- og Bredde-egenskapsverdiene i denne rektangulære strukturen.

Så, med det forrige rektangel, med negativ bredde og høyde, og derfor har koordinater [(-4, -6), (0, 0)], ville vi gjøre følgende antagelser:

[TestMethod] public void TestLeft () Rektangel r = nytt rektangel (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Forventet venstre == -4 men var" + r.Left);  [TestMethod] public void TestTop () Rektangel r = nytt rektangel (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "Forventet topp == 0 men var" + r.Top);  [TestMethod] public void TestRight () Rektangel r = nytt rektangel (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Forventet Høyre == 0 men var" + r.Right);  [TestMethod] public void TestBottom () Rektangel r = nytt rektangel (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Forventet nederst == -6 men var" + r.Bottom);

Dette er imidlertid ikke tilfelle:

Teste antagelser om rektangelegenskaper

Faktisk er bestemmelsen av topp og bunn også helt vilkårlig, da jeg har kjørt tester på nøyaktig samme rektangel dimensjoner og observert forskjellige resultater i Topp og Bunn eiendomsverdier.

Test antagelser om metode resultater

MSDN-dokumentasjonen sier at Rectangle.Intersect metode:

Returnerer en tredje rektangelstruktur som representerer krysset mellom to andre rektangelstrukturer.
Hvis det ikke er kryss, returneres et tomt rektangel.

Derfor kan vi lage en enkel test:

[TestMethod] public void TestIntersection () Rektangel r1 = nytt rektangel (0, 0, 10, 10); Rektangel r2 = nytt rektangel (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2), "Forventet R1 og R2 ikke å krysse."); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "Forventet et tomt kryssrektangel.");

med resultatet:

Testing Våre antagelser om metode returnerer

Dette informerer oss om at vår forventning, basert på dokumentasjonen, er feil.

For å konkludere

Enhetstesting er et viktig verktøy i testprosessen. Selv om integrering og brukervennlighetstesting ofte er mer kundeorienterte (rapportering, milepæler, verifisering av krav på høyt nivå), er enhetstesting den første forsvarslinjen for en programmerer, hans eller hennes lag og lagledere. Hvis du bruker det på en god måte (husk, du har ikke til hensikt å skape tusenvis av vakre grønne lys), kan det være en kostnadseffektiv måte å verifisere datakorrigasjonen til koden og for å gjenskape feil og kontrollere at de er løst.

En god enhetstesting krever imidlertid en disiplinert tilnærming, en forpliktelse til den tid og innsatsen som kreves for å implementere og vedlikeholde testene, og fra en koders perspektiv krever det også god programmeringspraksis og ofte håndhever arkitektoniske beslutninger. Sistnevnte kan fly i møte med "bare få det gjort" begrensninger (som kan være ganske legitime), og kan potensielt påvirke ytelsen. På oppsiden er programmeringspraksis og arkitekturer som enhetstesting krever å bruke, ofte til stor fordel for hele applikasjonsutviklingsprosessen, og dermed reduserer kostnadene og forbedrer vedlikeholdsbarheten, ikke fordi koden er enhetstestet, men fordi koden er skrevet bedre slik at den kan være enhetstestet.

Kode