unit-testing
Eenheidstesten: best practices

Invoering

Goede naamgeving

Het belang van goede naamgeving kan het best worden geïllustreerd door enkele slechte voorbeelden:

[Test]
Test1() {...} //Cryptic name - absolutely no information 

[Test]
TestFoo() {...} //Name of the function - and where can I find the expected behaviour?

[Test]
TestTFSid567843() {...} //Huh? You want me to lookup the context in the database?

Goede tests hebben goede namen nodig. Goede test test geen methoden, testscenario's of vereisten.

Goede naamgeving geeft ook informatie over context en verwacht gedrag. Idealiter zou u, wanneer de test op uw build-machine mislukt, moeten kunnen beslissen wat er mis is, zonder naar de testcode te kijken, of nog moeilijker, de noodzaak te hebben om deze te debuggen.

Goede naamgeving bespaart u tijd voor het lezen van code en foutopsporing:

[Test]
public void GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

Voor beginners kan het handig zijn om de testnaam te starten met ZorgThat_ of een vergelijkbaar voorvoegsel. Begin met een "Zorg dat" helpt om na te denken over het scenario of de vereiste, die een test nodig heeft:

[Test]
public void EnsureThat_GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void EnsureThat_GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

Naamgeving is ook belangrijk voor testopstellingen. Noem de testopstelling na de klasse die wordt getest:

[TestFixture]
public class OptionsTests //tests for class Options
{
    ...
}

De uiteindelijke conclusie is:

Goede naamgeving leidt tot goede tests, wat leidt tot een goed ontwerp in productiecode.

Van eenvoudig tot complex

Hetzelfde als bij het schrijven van klassen - begin met de eenvoudige gevallen en voeg vervolgens geval per geval vereiste (aka tests) en implementatie (aka productiecode) toe:

[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf4() {...}
[Test]
public void EnsureThat_IsNOTLeapYearIfDecimalMultipleOf100 {...}
[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf400 {...}

Vergeet niet de refactoring-stap, wanneer u klaar bent met de vereisten - refactor eerst de code, en refactor de tests

Als u klaar bent, moet u over een volledige, bijgewerkte en LEESBARE documentatie van uw klas beschikken.

MakeSut-concept

Testcode heeft dezelfde kwaliteitseisen als productiecode. MakeSut ()

• verbetert de leesbaarheid
• kan gemakkelijk opnieuw worden bewerkt
• ondersteunt perfect afhankelijkheid injectie.

Dit is het concept:

[Test]
public void TestSomething()
{
    var sut = MakeSut();
    
    string result = sut.Do();
    Assert.AreEqual("expected result", result);
}

De eenvoudigste MakeSut () retourneert gewoon de geteste klasse:

private ClassUnderTest MakeSUT()
{
    return new ClassUnderTest();
}

Wanneer afhankelijkheden nodig zijn, kunnen deze hier worden geïnjecteerd:

private ScriptHandler MakeSut(ICompiler compiler = null, ILogger logger = null, string scriptName="", string[] args = null)
{
    //default dependencies can be created here
    logger = logger ?? MockRepository.GenerateStub<ILogger>();
    ...
}

Je zou kunnen zeggen dat MakeSut slechts een eenvoudig alternatief is voor de setup- en verwijderingsmethoden die worden geleverd door Testrunner-frameworks en deze methoden misschien een betere plek bieden voor testspecifieke configuratie en verwijdering.

Iedereen kan zelf beslissen welke manier te gebruiken. Voor mij zorgt MakeSut () voor een betere leesbaarheid en veel meer flexibiliteit. Last but not least is het concept onafhankelijk van elk testrunner-framework.