Normalt forventer man, at hvis a + b giver c, så vil a + b altid give c.  I programmering skal man have en vis tolerance mht. præcision, når man bruger doubles og floats, men hvis a + b giver c i et program, forventer man samme resultat, uanset hvornår man laver beregningen indenfor samme proces.

Sådan troede jeg det var indtil fornylig, hvor én af vores unit tests fejlede – tilsyneladende lidt tilfældigt.  For kørte jeg den pågældende unit test alene, var der ingen fejl.  Kørte jeg den sammen med de andre unit tests i projektet, fejlede den.  Jeg fik ret hurtigt identificeret, hvilke andre unit tests, der drillede, og den fejlende unit test havde absolut intet med de andre unit tests at gøre.  Der var ingen fælles kode.

For nemheds skyld vil jeg kalde den fejlende unit test for A, og kalde de andre unit tests, som forårsagede fejlen i A for B. 

Test A tester kode indeholdende komplekse beregninger (Nelder-Mead), og fejlen gjorde, at det endelige resultat endte med en difference på 0.5!  Det er meget i min verden.

Test B er lidt speciel.  Den tester funktionalitet til at indlæse data fra et regneark.  Dvs. koden, som B tester, benytter Microsoft’s ACE driver. Efter en del test af denne driver, og noget der ligner to dages riven i mit eget hår, var jeg i stand til at genskabe problematikken med et simpelt eksempel, hvor resultat af et gangestykke med doubles gave forskellige resultater før og efter kald til ACE driveren.

Et spørgsmål på StackOverflow affødte en forklaring: “… unmanaged code may be tinkering with the FPU control word and change the way it calculates”.  Der blev også foreslået en løsning, nemlig et kald til _fpreset, som “resets the floating point package”.

Den foreslåede løsning virker, men jeg føler mig ikke overbevist om, at jeg egentlig har lyst til at bruge ACE driveren direkte i vores produktionskode.  En rådslagning med Daniel (også kendt er på sitet som ne0san) førte frem til en anden løsning, nemlig at spawn en ny process, som indlæser data fra regnearket, og kommunikerer data tilbage til hovedprocessen vha. named pipes (måske et emne for en kommende dotninjas blog).  Det virker.  Om det er en bedre løsning end _fpreset er svært at sige.

Hvis du har en masse test data i en Excel fil er der ingen grund til at kopiere det ind i dine tests - xUnit extensions kan ordne det for dig. Det er endda på en mege elegant måde.

Jeg har noget test data fra et gammel system som indeholder nogle tal for forskellige aldre. F.eks.

Age, Gamma, Sigma, Lambda, S

Jeg har 130 aldre i skridt på et kvart år. Hvert af de øvrige koloner svarer til det ønskede resultat af en funktion med samme navn givet alderen. Der findes altså funktioner Gamma(age), Sigma(age), Lambda(age) og S(age) på min klasse. Jeg vil gerne teste disse funktioner i hver deres test metode - ikke noget med at teste alle mulige funtioner i samme test metode (fy fy).

Det første du skal gøre er at finde dit test data frem i Excel og navngive området - inkl. kolonenavne. Enten ved at du bruger navneboksen til venstre for formellinjen eller "Name Manager" under "Formulas" (Du skal bruge "Name Manager" hvis du vil ændre eller slette navne). Dernæst gemmer du dit test data i Excel 97-2003 format (*.xls). Jeg har ikke fået det til at virke med det nye fancy pancy format.

Nu skriver du dine test metoder og klistrer de magiske attributer på:

[Theory]
[ExcelData("MyData.xls", "SELECT Age, Gamma FROM TestArea51")]
public void Gamma_Test(double age, double expected)
{
  // TODO: Place tests here (sorry about the methodname)
  var actual = ...

  Assert.Equal(expected, actual);  
}

Begge attributer kræver Xunit.Extensions som har sin egen Nuget pakke (og namespace med samme navn).

Det lille fancy SQL statement er muligt fordi vi har valgt at kolonenavne skal indgå i TestArea51 området. Så slipper vi for at ændre vores test hvis vi senere ønsker at udvidere området med mere test data. Bemærk at Excel navne svarer til et område inkl. arknavnet. Man kan altså ikke have samme område navn på forskellige ark - tilgengæld skal man heller ikke angive arknavnet i attributten ovenfor.

Når du kører testen vil den blive kaldt for hver række i dit test data - også selvom nogle rækker skulle fejle. Input data fremgår i test rapport hvis det fejler, så det er nemt at finde de rækker som ikke lever op til dine krav. Vær opmærksom på at GUI test runneren godt kan kløjs lidt i det hvis alt for mange rækker fejler. Jeg har med et snuptag fået 2000+ test bare på dette data - det er ret meget output hvis alle tests fejler.