Vanaf het moment dat Visual Studio 2005, inclusief alle test tools uitkwam, ben ik overgestapt van NUnit naar VS Test tools voor al mijn unit testing. Dat bevalt prima, ik loop eigenlijk nooit tegen problemen aan. Ik hou er van als alles geintegreerd in mijn omgeving is, de user interface is goed genoeg voor mijn doeleinden en ik hou graag alles bij elkaar. Dus de geintegreerde test omgeving voldoet prima!
Er is echter een maar: je moet wel de team edition hebben van Visual Studio. Professional is niet goed genoeg. En je raadt het al: ik zit momenteel bij een klant die geen licentie heeft voor de full blown versie van Visual Studio.
Dus hoewel ik gebruik maak van mijn eigen tools, moet ik rekening houden met de mogelijkheden van de klant: ik mag de test omgeving van Visual Studio niet gebruiken. Terug naar NUnit dus! Nou is dat geen straf. De tool werkt perfect, de userinterface is duidelijk... eigenlijk is het lood om oud ijzer. Tenminste....
Ik was vandaag een paar testclasses aan het schrijven, welke een assembly testen die wat data uit een database haalt. Uiteraard staat mijn connectionstring niet in de code maar die haal ik op uit de configuration bestanden. Geen probleem, zou je zeggen. Maar toch werkte het niet.
Mijn connectionstring werd niet gevonden. Na 4 keer controleren of ik geen typfouten had gemaakt, begon ik toch aan de omgeving te twijfelen. Dan maar even wat testjes er tegen aan gooien:
int counter = ConfigurationManager.ConnectionStrings.Count;
Dit gaf als resultaat: 1. Dat klopt, ik heb immers maar 1 config file.
We gaan verder:
string name = ConfigurationManager.ConnectionStrings[counter-1].Name;
We willen de laatste hebben. In mijn geval is er maar 1, en ik krijg als resultaat: LocalSqlServer. Heeee.. die ken ik! Die staat in mijn machine.config. Huh? Maarre... waarom vind .net nou niet mijn config file? Een blik in mijn bin\debug folder leert mij dat daar keuring netjes mijn DataLayer.dll.config staat: VS heeft hem goed gerenamed en gedeployed naar waar hij moet staan. Toch werkt het niet.
Op een helder moment maar even besloten een losse executable te maken en NUnit links te laten liggen. Hee. Nou doet 'ie het wel? Hmmm.. dan maar een VS Unit testje maken. Die werkt ook? Ah. Dus als ik NUnit gebruik krijg ik fouten, als ik iets anders doe werkt het.
Nog maar een testje doen. Leeg project, met 1 classlibrary die een string teruggeeft die uit de config komt, 1 classlibrary die de test voor NUnit bevat, 1 Test Project met een unittest.
Ok.... uhm.. nou doet 'ie het wel. Allemaal.
Even koffie drinken.
Ah. Er is een verschil tussen mijn laatste oplossing en het probleem project: bij het eerste had ik een NUnit project aan gemaakt in de NUnit GUI, bij de tweede had ik NUnit GUI opgestart en alleen de assembly toegevoegd. Even een project aanmaken in NUnit GUI en jawel: hij faalt. Goed, het is in ieder geval consistent.
Het volgende maar even proberen:
string configFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
Ah. Dat geeft terug c:\projects\MyNUnit.nunit.config. Dat is de naam van mijn NUnit project, niet de naam van de assembly!
Achteraf is het allemaal erg logisch, maar ik vind toch dat de VS geintegreerde oplossing beter is: nu moet ik in mijn post-build de .config renamen naar de juiste naam zodat NUnit hem ook vindt. Bij Visual Studio werkt het gewoon.
Het was weer een enerverende vrijdagmiddag :-)