UTT #1 - Tilstedeværelse af egenskaber på et interface

by Jesper maj 05, 2008 11:21

Det har været et par dage siden jeg sidst bloggede, da jeg ikke rigtigt har fundet rytmen i mit nye job, og dermed fundet den plads der skal til, for at skrible lidt på min blog. Jeg prioriterer disse skriverier temmelig højt, så jeg vil nu se, om jeg ikke kan få lidt mere flow på processen. Det vil måske resulterer i lidt kortere indlæg, men jeg vil forsøge at holde relevans indekset rimeligt højt :-)

Når du udvikler efter test først princippet, starter man ud med en test der beskriver / afprøver den funktionalitet man skal til at skrive / fremstille. Hvad nu hvis man skal lave et interface til et data transport lag eller andet? Man har jo ofte allerede en idé om hvilke properties interface skal have, og det virker måske lidt overkill at lave et mock-objekt til den opgave. Så var det jeg fik ideen at bruge reflection i min test.

[code=csharp][TestMethod] public void Skal_indeholde_properties() { MemberInfo[] properties = typeof(IArrangementslisteAdvanced).GetProperties(); Assert.IsNotNull(properties.FirstOrDefault(f => f.Name == "Aktivitet")); Assert.IsNotNull(properties.FirstOrDefault(f => f.Name == "Landsdele")); } [/code]

Nu har man en test der fejler ind til interfacet har implementeret alle de ønskede properties.

Tags:

Kommentarer

13-05-2008 22:23:58 #

Brian

Jeg er lidt forvirret her. Et interface implementerer jo ikke noget, og derfor er der heller ikke noget at teste i et interface. Et interface erklærer kun en kontrakt. En type kan implementere et interface ved at implementere metoder/properties i kontrakten, men interfacet i sig selv er jo ikke så interessant set med testøjne.

Hvad synes du din test giver som compileren ikke allerede håndterer?

Brian

Brian Denmark

13-05-2008 22:48:55 #

Jesper

Hvis du bruger interfacet som kontrakt, kan det give god mening at havde en test der checker at du overholder kontrakten, og det kan man jo ikke nødvendigvis fange i kompileren.

Jesper Denmark

15-05-2008 13:31:46 #

Brian

Hej igen - jeg er ikke sikker på at min pointe kom helt igennem, så lad mig prøve igen.

Du skriver ganske rigtig, at hvis man arbejder efter test først-princippet, så skriver man test, inden man implementerer funktionalitet, men en interface-specifikation er jo netop *ikke* funktionalitet. Et interface er en hensigtserklæring. Hvis ingen typer implementerer dit interface, er der jo reelt ingen reel kode på spil her.

Interfaces er en rigtig stærk feature, men de er blot en sprogfeature, der gør, at vi kan skrive kode, der er en anelse løsere koblet. Uden egentlige implementeringer i konkrete typer er interfaces jo uinteressante.

I bedste fald fungerer din test som en huskeliste. Hvis du vil udvide dit interface, antager jeg derfor, at du tilføjer en Assert, der verificerer at din udvidelse er til stede. Denne test vil naturligvis fejle. Derefter kan du så tilføje til dit interface, hvorefter compileren vil brokke sig over at de typer, der implementerer dit interface ikke implementerer din nye udvidelse. Herefter kan du skrive de reelle test af den ny funktionalitet (og derefter implementere den).

Så lad mig vende den en omgang: Hvilke fejl forestiller du dig, at ovenstående test vil fange?

Brian Denmark

16-05-2008 08:08:41 #

The IMan

Konkret vil den fange, hvis man ændre interfacet...
Jeg starter med at skrive en sådan test, ud fra en user-story, og på den måde fungerer den som en huskeseddel om den kontrakt storyen beskriver. TDD er meget en måde at arbejde på, og en del af de tests der laves, ser måske ikke ud til at checke særligt meget, og nogle vil måske springe over. Laver alle f.eks. test af en parameter-løs konstruktør? Nej vel, men det er et spørgsmål om temperament, og så er det først og fremmest en måde at arbejde på, ikke en eksakt videnskab..

The IMan Denmark

16-05-2008 18:40:25 #

Brian

Nej, det vil den jo netop ikke i alle tilfælde. Hvis du ændrer en eksisterende property, vil den slå ud, men hvis du tilføjer en property eller metode, vil din test jo ikke slå ud, men det vil compileren derimod.

Det, jeg reagerer på, er at du skriver, at det går ud på at bruge test til at verificere funktionalitet, men et interface er jo netop ikke funktionalitet.

Mht. en default constructor synes jeg da ikke, at der er nogen grund til at springe test af denne over. Det kan jo netop være relevant at verificere den indledende tilstand - det er jo trods alt en del af funktionaliteten.

Anyway, vi kommer det nok ikke nærmere. Jeg synes, det er rigtig godt, at du bruger TDD. Jeg er bare ikke helt enig med dig i gevinsten her.

Brian

Brian Denmark

Kommentarerne er lukkede

Powered by BlogEngine.NET 1.5.0.7
Theme by Mads Kristensen | Modified by Mooglegiant

About

Mit navn er Jesper Jensen, og jeg arbejder til dagligt som web-udvikler hos DGI, hvor mit speciale er klientside applikationer. Før det var jeg nogle år i robotbranchen, hvor jeg arbejdede med 3D simulering og system koordinering. Jeg elsker webudvikling, og specielt JavaScript har min interesse. Jeg har blogget om mine oplevelser med udvikling siden 2004

Calendar

<<  juli 2010  >>
mationtofr
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar

RecentComments

Comment RSS