Olen lopettanut mocking kirjaston käyttämisen. Tässä on syy

#dotnet #testing

ℹ️ Opin suomea
Tämä on mulle harjoitus oppimaan suomea. Voit myös lukea englanniksi.

Se tuntuu ihan itsestään selvältä: Kun luot uuden unit-testing projektin, asennat Moq tai NSubtitute myös. Miten muuten vaihdat riipuvuuden test-double-ksi? Olet hölmö kun kirjoitat omat test-double-t, eikö niin? Tässä artikkelissa, haluaisin vakuuttaa sinut että se ei ole niin hölmö kuin ajattelet.

Testien luettavuus on parannettu

On helpommin näytetty esimerkissä. Tässä on esimerkki NSubstituten kanssa:

[Fact]
public void ShouldGetUserNameById()
{
    // given
    var userRepository = Substitute.For<IUserRepository>();
    userRepository.GetById(1234).Returns(new User(userName: "JohnDoe"));
    var userService = new UserService(userRepository);

    // when
    var result = userService.GetUserNameById(1234);

    // then
    Assert.Equal("JohnDoe", result);
}

Se ei ole huono. Vertaillaan sitä ja testiä joka käyttää mukautettua test-double:

[Fact]
public void ShouldGetUserNameById()
{
    // given
    var userRepository = new FakeUserRepository()
        .WithUser(id: 1234, userName: "JohnDoe");
    var userService = new UserService(userRepository);

    // when
    var result = userService.GetUserNameById(1234);

    // then
    Assert.Equal("JohnDoe", result);
}

Testillä joka käyttää mukautettua test-double on vähempi sanoja. Tämä näyttää merkityksettömältä, mutta ero tulee huomattavaksi kun käytät monta test-double.

Testit tulee itsenäisempi toteutuksesta

Esimerkissä näet että versio joka käyttää NSubstitutea määrittää vain yhteen funktioon tuloksen. Versiolla joka käyttää mukautettua test-double ei ole mitään viiteitä funktioihin. Tuo tarkoittaa että on vain yhteys test-double-n kanssa, mutta ei ole suoraa yhteystä oikean funktion kanssa. Siksi oikea funktio on helpompi muuttaa. Eli, ei mun tarvitse muuttaa kaikkea testeja kun muutan funktion.

Lisäksi, mulla on lisää vapaus toteuttaa ominaisuuden. Versio joka käyttää NSubstitutea on riipuvainen toteutuksen yksityiskohtasta: funktiopuhelu jota käytän toteutukseksi. Joskus on monta tapaa saavuttaa tavoitteen, mutta mocking kirjasto vaatii valita ratkaisun ennen toteuttamisen. Tämä voisi olla hankala.

Mulla on nyt kätevät työkalut

Kun totut kirjoittamiseen omia test-double-ia, alat kerätä käteviä työkaluja joita kiihdyttävät testikirjoitamisen. Mulla on työkalut:

Asetuksille IOptionsMonitor<...>n avulla
API pyyntille ja vastauksille HttpClientin avulla
Umbracon IPublishedContentille, modelsbuilder mallille, sivu navigointille ja URL luomisille
TelemetryClientille Application Insightsista

Tästä syystä olen myös löytänyt olemassa olevia työkaluja päivämäärille ja kirjauksille. Näiden työkalujen avulla testeistä tulee helpompia lukea ja kirjoittaa.

TDD tuntuu luonnollisempi

Tämä on henkilökohtainen syy kuinka pidän testien kirjoittamisesta. Kuvittelen miten testi voisi näyttää ja ensin kirjoitan sitä. Yleensä testit eivät käännä, koska mä keksin funktiot, tyypit ja ominaisuudet jotka eivät vielä ole olemassa. Tämä on erityisen tehokas tekoälyavustajan kanssa, koska se on ihan taitava saamaan koodit valmiiksi. Tämä on vaikeampi mocking kirjaston avulla, koska mun pitää ensin ajatella kirjaston käytämisestä ja unohdan ajatella miten testi pitäisi näyttää. Ajattelen toteutuksesta ennen kuin olen ajattelut suunnittelusta.

Johtopäätös

Oman test-double-n tekeminen ei ole niin hölmö kuin ajattelet. Mocking kirjastot ovät voimakkaat työkalut, mutta sun ei pitäisi aliarvioida miten paljon voit tehdä oman yksinkertaisen test-double-n avulla. Ne parantavat testien luettavuutta ja voisivat tehdä testit itsenäisempi toteutuksesta.

Kiitos lukemisesta ja nähdään ensi blogissa! 😊

DEV Community