Tot slot

Dit is een uittreksel uit het Unit Testing Beknopte eBook, door Marc Clifton, vriendelijk geleverd door Syncfusion.

Het testen van eenheden is ook waardevol voor andere doeleinden.

Als voorbeelden van gebruik

Een van de voordelen van het testen van eenheden is dat het een grote codebasis creëert die een voorbeeld is van het gebruik van de code. Bijvoorbeeld de code die we eerder zagen:

[Test] public void FilenameParsingTest () Woordenboek options = CommandLineParser.Parse ("- f foobar"); Assert.That (options.Count == 1, "Count wordt naar verwachting 1"); Assert.That (options.ContainsKey ("- f"), "Expected option '-f'"); Assert.That (options ["- f"] == "foobar");

documenteert een verwachte geldige use case voor de commandoregel-parser. Overweeg ook eenheidstests te schrijven - niet alleen voor uw eigen code, maar ook om voorbeelden te geven voor bibliotheken van derden. (Zie volgende voorbeelden en de interessante dingen onthuld over de Rectangle struct.)

Black Box testen

Black Box testen gaat ervan uit dat je niets weet over de interne onderdelen van de klas of service en zijn gedrag strikt verifieert van de openbaar belichte interfaces. Dit is vaak nodig als u de code niet beschikbaar heeft. Toen we bijvoorbeeld met een platenmaatschappij werkten, moesten we een webservice van een overheidsinstantie gebruiken om de records bij te werken. Door unit tests voor de webservice te schrijven, konden we bewijzen dat de aan ons verstrekte documentatie niet resulteerde in het verwachte gedrag van de webservice.

U kunt deze techniek ook gebruiken bij het werken met code die door verschillende afdelingen wordt geleverd. De databasegroep kan bijvoorbeeld zijn eigen white box-unittest hebben; u moet echter ook controleren of vanuit een black-box-perspectief de triggers en beperkingen correct zijn geprogrammeerd door het resultaat van transacties te inspecteren op basis van de functionaliteit die aan u is blootgesteld.

Test uw aannames

Unit-testen kan een eenvoudige manier zijn om een aantal tests samen te stellen met betrekking tot onze veronderstellingen over een API. Laten we de. Nemen System.Drawing.Rectangle structureer en test enkele schijnbaar redelijke aannames over de implementatie.

Test Aannemer Aannames

Er zijn er twee Rechthoek constructeurs: een met Punt en Grootte parameters, terwijl de andere de parameters x, y, width en height heeft. De documentatie geeft geen indicatie of de grootte (de breedte of hoogte) positief moet zijn, dus laten we een test schrijven om te verifiëren dat we een rechthoek met een negatieve breedte of hoogte kunnen construeren:

[TestMethod] public void RectangleNegativeSizeConstructorTest () Rectangle r = new Rectangle (0, 0, -4, -6);

Alles wat we hier in deze test doen, is controleren of er geen uitzonderingen worden gegenereerd wanneer we de rechthoek construeren, en inderdaad is dit het geval:

Rechthoek Constructor Test

Test aannames met betrekking tot eigenschapswaarden

Laten we nu onze aannames over bepaalde eigenschappen testen. De eigenschappen Top, Links, Bodem, en Rechts worden beschreven als (zie
http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.aspx):

Boven: haalt de y-coördinaat van de bovenrand van deze rechthoekstructuur.

Links: haalt de x-coördinaat van de linkerrand van deze rechthoekstructuur.

Onderste: verkrijgt de y-coördinaat die de som is van de Y- en Height-eigenschapswaarden van deze rechthoekstructuur.

Rechts: haalt de x-coördinaat op die de som is van X en Breedte eigenschapswaarden van deze rechthoekstructuur.

Dus, met de voorgaande rechthoek, met een negatieve breedte en hoogte, en dus met coördinaten [(-4, -6), (0, 0)], zouden we de volgende veronderstellingen maken:

[TestMethod] public void TestLeft () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Verwacht links == -4 maar was" + r.Links);  [TestMethod] public void TestTop () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "verwachte Top == 0 maar was" + r.Top);  [TestMethod] public void TestRight () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Verwacht rechts == 0 maar was" + r.Right);  [TestMethod] public void TestBottom () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Verwachte onder == -6 maar was" + r.Bottom);

Dit is echter niet het geval:

Veronderstellingen testen over rechthoekeigenschappen

De bepaling van boven en onder lijkt zelfs volledig willekeurig, omdat ik tests heb uitgevoerd op precies dezelfde rechthoekdimensies en verschillende resultaten heb waargenomen in de Top en Bodem eigendomswaarden.

Testaannames over methodesultaten

In de MSDN-documentatie staat dat de Rectangle.Intersect methode:

Retourneert een derde rechthoekstructuur die de kruising van twee andere rechthoek-structuren vertegenwoordigt.
Als er geen kruising is, wordt een lege rechthoek geretourneerd.

Daarom kunnen we een eenvoudige test maken:

[TestMethod] public void TestIntersection () Rectangle r1 = new Rectangle (0, 0, 10, 10); Rectangle r2 = new Rectangle (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2), "Verwacht dat R1 en R2 elkaar niet kruisen."); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "Verwacht een lege intersectierandrechthoek.");

met het resultaat:

Het testen van onze aannames over retouren van methoden

Dit informeert ons dat onze verwachting, gebaseerd op de documentatie, onjuist is.

Tot slot

Het testen van eenheden is een belangrijk hulpmiddel in het testproces. Hoewel testen van integratie en bruikbaarheid vaak klantgerichter zijn (rapportage, mijlpalen, controleren van hoge eisen), is unit testing de eerste verdedigingslinie voor een programmeur, zijn of haar team en de teammanagers. Als je verstandig gebruikt wordt (denk eraan, je bent niet van plan om duizenden mooie groene lichten te maken), kan het een kosteneffectieve manier zijn om de computationele correctheid van de code te verifiëren en bugs opnieuw te maken en te verifiëren dat ze zijn opgelost.

Goede testprocedures voor eenheden vereisen echter een gedisciplineerde aanpak, een toewijding aan de tijd en moeite die vereist is om de tests uit te voeren en te onderhouden, en vanuit het oogpunt van een codeerder zijn er ook goede programmeerpraktijken vereist en worden vaak architecturale beslissingen afgedwongen. Deze laatste kan vliegen in het aangezicht van "het gewoon voor elkaar krijgt" -beperkingen (wat heel legitiem kan zijn) en kan mogelijk van invloed zijn op de prestaties. Enerzijds zijn de programmeermethoden en -architecturen die eenheidstests afdwingen vaak een groot voordeel voor het gehele ontwikkelingsproces van de toepassing, waardoor de kosten worden verminderd en de onderhoudbaarheid wordt verbeterd, niet omdat de code een eenheidstest heeft, maar omdat de code beter is geschreven zodat het kan unit getest.

Code