Sammanfattningsvis

Detta är ett utdrag från Unit Testing Succinctly eBook, av Marc Clifton, vänligt tillhandahållen av Syncfusion.

Enhetstestning är också värdefull för andra ändamål.

Som exempel på användning

En av fördelarna med enhetstestning är att den skapar en stor kodbas som exempel på hur man använder koden. Till exempel koden vi såg tidigare:

[Test] public void FilenameParsingTest () Dictionary alternativ = CommandLineParser.Parse ("- f foobar"); Assert.That (options.Count == 1, "Count förväntas vara 1"); Assert.That (options.ContainsKey ("- f"), "Förväntat alternativ" -f ""); Assert.That (alternativ ["- f"] == "foobar");

dokumenterar ett förväntat giltigt användningsfall för kommandoradsparsern. Också överväga att skriva enhetstester, inte bara för din egen kod, men också för att ge exempel på bibliotek från tredje part. (Se efterföljande exempel och de intressanta sakerna som avslöjades om rektangelstrukturen.)

Black Box Testing

Svart boxningstest antar att du inte vet någonting om klassen eller tjänstens internaler och kontrollerar sitt beteende strikt från de offentligt utsatta gränssnitten. Detta är ofta nödvändigt när du inte har koden tillgänglig. Till exempel, när vi arbetade med ett rekordhanteringsföretag, var vi skyldiga att använda en webbtjänst som tillhandahålls av en statlig myndighet för att uppdatera poster. Genom att skriva enhetstest för webbtjänsten kunde vi bevisa att den dokumentation som lämnades till oss inte resulterade i webbtjänstens förväntade beteende.

Du kan också använda den här tekniken när du arbetar med kod som tillhandahålls av olika avdelningar. Exempelvis kan databasgruppen ha sin egen vita boxenhetstestning; Du bör dock också verifiera att utlösare och begränsningar från ett svart boxperspektiv har programmerats korrekt genom att inspektera resultatet av transaktioner från den funktionalitet som utsätts för dig.

Testa dina antaganden

Enhetstestning kan vara ett enkelt sätt att sammanställa några test om våra antaganden om ett API. Låt oss ta System.Drawing.Rectangle strukturera och testa några till synes rimliga antaganden om genomförandet.

Testkonstrukternas antaganden

Det finns två Rektangel konstruktörer: en som har Punkt och Storlek parametrar, den andra har x, y, bredd och höjdparametrar. Dokumentationen ger ingen indikation om storleken (bredden eller höjden) måste vara positiv, så låt oss skriva ett test för att verifiera att vi kan konstruera en rektangel med negativ bredd eller höjd:

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

Allt vi gör här i det här testet är att verifiera att inga undantag kastas när vi konstruerar rektangeln, och det är faktiskt så här:

Rektangelkonstruktortest

Testa antaganden om egenskapsvärden

Låt oss nu testa våra antaganden om vissa egenskaper. Egenskaperna Topp, Vänster, Botten, och Höger beskrivs som (se
http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.aspx):

Topp: Hämtar y-koordinaten i den övre kanten av denna rektangelstruktur.

Vänster: Går x-koordinaten till den vänstra kanten av denna rektangelstruktur.

Bottom: Får y-koordinaten som är summan av egenskaperna Y och Höjd för denna rektangelstruktur.

Höger: Hämtar x-koordinaten som är summan av X- och Bredd-egenskapsvärdena för denna rektangelstruktur.

Så, med den föregående rektangeln, med en negativ bredd och höjd, och därför har koordinater [(-4, -6), (0, 0)], skulle vi göra följande antaganden:

[TestMethod] public void TestLeft () Rektangel r = ny rektangel (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Expected Left == -4 men var" + r.Left);  [TestMethod] public void TestTop () Rektangel r = ny rektangel (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "Expected Top == 0 men var" + r.Top);  [TestMethod] public void TestRight () Rektangel r = ny rektangel (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Expected Right == 0 men var" + r.Right);  [TestMethod] public void TestBottom () Rektangel r = ny rektangel (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Expected Bottom == -6 men var" + r.Bottom);

Detta är emellertid inte fallet:

Testa antaganden om rektangelegenskaper

Faktum är att bestämningen av topp och botten också är helt godtycklig, eftersom jag har testat på exakt samma rektangelmått och observerade olika resultat i Topp och Botten fastighetsvärden.

Testa antaganden om metodresultat

I MSDN-dokumentationen anges att Rectangle.Intersect metod:

Returnerar en tredje rektangelstruktur som utgör korsningen mellan två andra rektangelstrukturer.
Om det inte finns någon korsning returneras en tom rektangel.

Därför kan vi konstruera ett enkelt test:

[TestMethod] public void TestIntersection () Rektangel r1 = ny rektangel (0, 0, 10, 10); Rektangel r2 = Ny rektangel (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2), "Förväntad R1 och R2 inte korsa."); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "Förväntad en tom korsning rektangel.");

med resultatet:

Testa våra antaganden om metod returnerar

Detta informerar oss om att vår förväntan, baserat på dokumentationen, är felaktig.

Sammanfattningsvis

Enhetstestning är ett viktigt verktyg i testprocessen. Medan integrations- och användbarhetsprovning ofta är mer kundcentrerad (rapportering, milstolpar, verifiering av högkvalitativa krav) är enhetstestning den första försvarskoden för en programmerare, hans eller hennes lag och lagledarna. Om det används judiciously (kom ihåg, du syftar inte till att skapa tusentals vackra gröna lampor), det kan vara ett kostnadseffektivt sätt att verifiera beräkningsberäkningen av koden och för att återskapa fel och verifiera att de har blivit fixade.

Goda testningspraxis kräver dock ett disciplinerat tillvägagångssätt, ett engagemang för den tid och ansträngning som krävs för att genomföra och behålla testen, och från en kodarens perspektiv kräver det också goda programmeringsmetoder och verkställer ofta arkitektoniska beslut. Den senare kan flyga inför "bara få det gjort" begränsningar (vilket kan vara ganska legitimt) och kan eventuellt påverka prestanda. På uppsidan är de programmeringsmetoder och arkitekturer som enhetsprovning tvingar att använda, ofta till stor nytta för hela applikationsutvecklingsprocessen, vilket minskar kostnaderna och förbättrar underhållet, inte för att koden är enhetstestad, men eftersom koden skrivs bättre så att det kan testas enhetligt.

Koda