Data bij unit testing

[PdeBie]

Hoi allen,

ik ben bezig met het ontwikkelen van een API en daarbij ga ik gebruik maken van unit testing. Mijn vraag echter, hoe gaan jullie om met data tijdens unit testing?

Zorgen jullie voor een vaste dataset alvorens je de unit tests start? Of gebruiken jullie gewoon de data zoals hij op dat moment is want "in productie zou het ook zo moeten werken"?

Even benieuwd hier naar

Dank je wel.

[roy-t]

Voor unit tests zou je altijd vaste data moeten gebruiken. Niets is erger dan een unit test die het soms niet doet!

Voor vervelende dingen zoals databases gebruik ik zelf Effort (een in-memory database die je met 1 functie call kan reverteren naar de vorige versie).

[Haan]

Of gebruiken jullie gewoon de data zoals hij op dat moment is want "in productie zou het ook zo moeten werken"

Dit lijkt te impliceren dat je in je unit test data opvraagt (uit een database/webservice/whatever), dat is sowieso geen best practice. De datalaag zou je in je unit tests moeten mocken of je hangt er een repository aan met fixed data.

[PdeBie]

Haan schreef op maandag 14 december 2015 @ 13:31:
[...]

Dit lijkt te impliceren dat je in je unit test data opvraagt (uit een database/webservice/whatever), dat is sowieso geen best practice.

Een van de functies is bijvoorbeeld: GetProduct(int productId);

Dat zou toch ook getest moeten worden lijkt mij? Of maak jij geen Unit Tests voor dit soort functies?

[Haan]

Ja. maar je gaat dat niet op een live database testen, dan ben je stiekem ook aan het testen of je database connectie werkt Je kan dat prima testen op een in-memory lijst van producten die je in code definieert.

[CurlyMo]

Ja, maar je wilt ook weten of daadwerkelijk het juiste product wordt opgehaald.

Je voert dus eerst een product in, haalt daarna het product op met het bijbehorende productId dat je al weet en kijkt of beide matchen. Anders ligt in één van beide stappen een fout. Nu weet je niet of het product dat je terug krijgt hoort bij het productId.

[Avalaxy]

Haan schreef op maandag 14 december 2015 @ 13:34:
Je kan dat prima testen op een in-memory lijst van producten die je in code definieert.

Niet mee eens, dan test je heel je SQL niet. Laat nou juist SQL iets zijn dat lastig te refactoren is (want niet statically typed). Dan is het handiger om een in-memory database neer te zetten, te seeden met data en die weg te gooien aan het eind van je test.

[PdeBie]

OK, dus gewoon even een functie maken die test data maakt, bijvoorbeeld:

C#:

private static List<Product> GetTestProducts()
        {
            return new List<Product> {
                new Product { Id = 1, Name = "Product 1", Price = 1 },
                new Product { Id = 2, Name = "Product 2", Price = 3.75M },
                new Product { Id = 3, Name = "Product 3", Price = 16.99M },
                new Product { Id = 4, Name = "Product 4", Price = 11.00M }
            };
        }

of hiermee een in-memory database vullen om mijn queries te testen.

[mulder]

Avalaxy schreef op maandag 14 december 2015 @ 13:35:
[...]


Niet mee eens, dan test je heel je SQL niet. Laat nou juist SQL iets zijn dat lastig te refactoren is (want niet statically typed). Dan is het handiger om een in-memory database neer te zetten, te seeden met data en die weg te gooien aan het eind van je test.

Dat is een integratietest, geen unit test. Development time is in-memory database wel een prettige manier van ontwikkelen.

[Avalaxy]

Als je alleen je repository-method test en niet alle logica die daar voor zit dan is het mijns inziens toch echt een unit test; je test immers alleen de functie die data ophaalt. Maargoed, semantics. Maak me weinig uit hoe mensen het noemen

[Verwijderd]

Het idee achter een unit test is dat je de functie die je test isoleert van de andere onderdelen in je applicatie. Ook wil je vaak graag meerdere scenario's testen dus is het handig dat je de data kan manipuleren.
Door vooraf je data te bepalen weet je ook wat de verwachte uitkomst moet zijn en dit is noodzakelijk bij een unit test.

Conclusie: Niet tegen een live database testen, maar je dataset vooraf specificeren en een database met testdata gebruiken

[Verwijderd]

PdeBie schreef op maandag 14 december 2015 @ 13:38:
OK, dus gewoon even een functie maken die test data maakt, bijvoorbeeld:

C#:

private static List<Product> GetTestProducts()
        {
            return new List<Product> {
                new Product { Id = 1, Name = "Product 1", Price = 1 },
                new Product { Id = 2, Name = "Product 2", Price = 3.75M },
                new Product { Id = 3, Name = "Product 3", Price = 16.99M },
                new Product { Id = 4, Name = "Product 4", Price = 11.00M }
            };
        }

of hiermee een in-memory database vullen om mijn queries te testen.

Kan. Ik prefereer liever persoonlijk om een (test/development) database te seeden met pseudo-echte data, zodat je met data werkt wat lijkt op echte data. Zelf gebruik ik bijvoorbeeld voor PHP vaak Faker. Op die manier ben je ook niet geneigd om tests te schrijven die misschien afhankelijk gaan worden van je testdata, terwijl je dat misschien niet wilt.
Een ander voordeel is dat je gewoon kunt zeggen: "Seed voor deze test maar even 100 producten in de database", zonder dat je 100 regels code moet gaan zitten schrijven. Of 1000. Of 10000. Het ligt er maar net aan wat je wilt doen.
Een ander belangrijk punt is dat je jezelf moet afvragen: "Wat ben ik aan het testen?". Test je de database connectie? Test je of de resultaten uit de query correct zijn en overeen komen met data die ook daadwerkelijk in je tabellen staan? Of test je of je applicatie correct om kan gaan met objecten die een model moeten voorstellen? Of test je of je presenters de data uit je modellen correct laten zien? Enzovoort.

[ Voor 4% gewijzigd door Verwijderd op 16-12-2015 11:06 ]

[Verwijderd]

Kijk eens naar mocking frameworks. Desnoods data vanuit een xml gebruiken, tevens handig voor de testers in het team kunnen ze gemakkelijk testdata manipuleren.

[Avalaxy]

Voor data genereren kun je AutoFixture gebruiken met .NET Werkt ook samen met Moq.

[marcelk1607]

Mockito gebruiken, en als je al echte data wilt gebruiken gebruik bijvoorbeeld csv of XML bestanden zodat je junit code klein blijft.

[jip_86]

Ben het bij ons ook aan het uitvogelen. We gebruiken daarvoor geen sql db maar een memory db. Daar test ik vooral met data voor specifieke scenario's. Je wil bijvoorbeeld testen of een vervallen product te bestellen is. Dan heb je in feite genoeg aan een vervallen record (ok misschien ook een die niet vervallen is om het tegenovergestelde ook te testen ). Samen met in memory testen is het ook nog eens rete snel te testen omdat je niet naar de db toe hoeft en het heel makkelijk weer kan herstellen om je tests elke keer hetzelfde af te kunnen draaien.

[Hydra]

marcelk1607 schreef op zaterdag 26 december 2015 @ 22:02:
Mockito gebruiken, en als je al echte data wilt gebruiken gebruik bijvoorbeeld csv of XML bestanden zodat je junit code klein blijft.

Mocking heeft niet zo heel veel te maken met de (soort van) integratie tests die hij wil doen. Daarvoor kun je 't beste een in-memory DB gebruiken. Dan kun je altijd nog in je deployment scripts de tests draaien tegen een 'echte' DB.

PdeBie schreef op maandag 14 december 2015 @ 13:22:
Zorgen jullie voor een vaste dataset alvorens je de unit tests start?

Elke test moet uit kunnen gaan dat, ongeacht de volgorde waarin ze uitgevoerd worden, de data correct is voor de test. Anders kun je ze bijvoorbeeld niet parallel laten lopen.

Of gebruiken jullie gewoon de data zoals hij op dat moment is want "in productie zou het ook zo moeten werken"?

Tuurlijk niet. Dan vallen om de haverklap je tests om. En je test hopelijk ook niet tegen prod aan.

[ Voor 29% gewijzigd door Hydra op 28-12-2015 16:47 ]

[Matis]

Persoonlijk ben ik bij unit testen van mening de units zo klein mogelijk te houden.
Met zo min mogelijk kans op falen door invloeden van buitenaf.

Daarnaast is het zinnig om de unit te specificeren welke je wilt testen. Als dat ook de connectie met een database omvat dan hoef je niet te mock-en.

Anders ben ik het eens met degene boven mij.

[marcelk1607]

Ik snap niet waarom je data nodig hebt voor je tests.
Je geeft aan dat je een API wilt unit testen, dan kun je ook pure unit tests maken met Mockito.
Integratietesten zijn wat anders dan unit tests.

[PdeBie]

marcelk1607 schreef op maandag 28 december 2015 @ 18:34:
Ik snap niet waarom je data nodig hebt voor je tests.

Stel ik heb een hele basale functie 'GetCar(int carId)'.
Dan moet ik toch kijken of deze functie het juiste object terug geeft? Daar heb je toch data voor nodig?

[Janoz]

Wat ben je aan het testen? Je functie, of de complete database. Afhankelijk van hoe je je applicatie opgezet hebt kun je keurig je DAO mocken. Je DAO zelf testen lijkt me eerder iets dat je in je integratietest meeneemt. Een GetCar(int carId) welke vervolgens een object teruggeeft dat in de database staat is mijn inziens gewoon een integratietest.

[incaz]

Waarbij je overigens natuurlijk best kunt beslissen dat integratietests belangrijker zijn dan unittests. Ik ben wat dat betreft meer uit de pragmatische hoek: laat tests vooral testen waar het zwaartepunt ligt, waar het het vaakst misgaat, waar de meeste winst te behalen is.

Bij veel applicaties waar de nadruk meer ligt op data-opslag en weergave en minder op algoritmes, zijn tests die meer richting integratie wellicht dan ook belangrijker - het net dat fouten vangt heeft dan wat grovere mazen, maar is ook stukken makkelijker op te zetten en vangt meer de dingen die je wilt. En als je 'getCar(int id)' dan een fout resultaat teruggeeft kun je altijd nog terugvallen op het controleren van de kleinere eenheden, terwijl de unittests op zich te klein zijn om echt van nut te zijn. Als je programmeerwerk meestal het handelen van views is, richt dan ook vooral je focus daarop.

Een andere afweging is performance. Het is de bedoeling dat je tests zo makkelijk mogelijk kunt runnen, zonder dat je weer terug bent bij het wachten op eindeloos compilerende code.
Voor de tests die je voortdurend of in elk geval heel vaak laat lopen zou ik alleen al daarom in elk geval testdata gebruiken, waarin je bovendien zorgt dat je alle edge cases representeert. Zo spoor je het snelst fouten en regressions op. Live-data is meestal erg veel, en wellicht komt een bepaalde edge-case helemaal niet voor (of niet op dat moment.)

Maar af en toe ook een test laten lopen tegen live-data kan zeker ook nuttig zijn, want de werkelijkheid blijkt soms toch vreemder dan je met je edgecases kunt bedenken. (En... Het werkte zo leuk bij je 50 testrecords. Maar op de set van 5000 ging het ineens toch nog mis ergens rond id 3000 omdat iets bepaalds stiekem exponentieel blijkt te zijn ipv lineair.....)

[drm]

Het verschil tussen unit tests en integratietests (en functionele tests als de derde trap) wordt nog wel eens aangehaald, maar ik vind het persoonlijk best wel belangrijk om te weten waar je het over hebt, omdat je namelijk een idee moet hebben van wat je precies aan het testen bent.

Een van de belangrijkste aspecten van een test is namelijk een idee van wat de test precies covert. Met andere woorden, als datgene wat hij covert stukgaat, dan moet de test falen. Je zou zeggen dat het handig is als een test zoveel mogelijk covert, maar daarmee identificeert de test ook des te minder goed wat er precies stuk is zodra dat aan de orde is. Bijvoorbeeld: door een applicatie heenklikken covert heel veel, maar als je foutmeldingen krijgt moet je stacktraces gaan napluizen om te zien wat er nou precies aan de hand is.

Daarom is het een goed idee om zoveel mogelijk te coveren met unit tests. Met een unit test maak je een test met een aantal cases (omstandigheden), die 1 stukje code onafhankelijk van andere "werkzame" componenten testen. Het voordeel van je "units under test" zo klein mogelijk (atomair) te houden is dat als een unit test faalt, de case (de omstandigheden) heel duidelijk identificeert waarin de unit (het stuk code dat getest wordt) faalt.

Als je unit test daarvoor data nodig heeft, dan zijn dat in principe dus gewoon verschillende testcases. PHPUnit (het testing framework dat ik het beste ken) heeft daarvoor iets dat je een 'dataprovider' noemt die 'data fixtures' levert voor een testcase. Dat is handig als je verschillende stukjes data nodig hebt om dezelfde testcode mee uit te voeren. Maar tenzij je een enorme hoeveelheid testdata aan relevante (en onderscheidende) test cases hebt, is dat eigenlijk alleen maar een convenience en niet eens per se een best practice.

Voor unit tests zijn termen als "Principle of Least Knowledge" en "Design by Contract" handig om op te googlen. Als je iets niet goed kunt unit testen, is er waarschijnlijk sprake van een overtreding van "Demeter's Law" en geen of slecht geimplementeerd "Design by Contract". Andersom, als je heel makkelijk ergens een test voor kunt maken is er waarschijnlijk sprake van weinig dependencies, of dependencies die zich netjes aan een "design by contract" houden.

Daarom komen in het kader van unit tests ook altijd de termen "mock" en "stub" aan de orde. In het kort komt het er op neer dat als je een "stub" maakt, je een soort voorgeprogrammeerde implementatie van een dependency aan de unit under test meegeeft . Een mock gebruik je om de interne werking van de unit under test te verifieren (denk aan "Houdt de unit er wel rekening mee dat de return value van deze method ook null kan zijn in sommige gevallen?"). [1]

Heb je het echter over integratietests, dan wil je weten of al die units die je aan elkaar knoopt als geheel doen wat ze moeten doen. Meestal gebruik je bij integratietests geen stubs en/of mocks meer maar ga je na of een "real life" implementatie doet wat het moet doen. Daarom heb je bij integratietests ook vaak externe dependencies (zoals een database, een internetverbinding, of zelfs een filesystem). Dat neigt al een beetje naar functioneel testen. In principe is het een good practice (vind ik ) om integratietests alleen toe te passen waar je situaties mee covert die wel kritisch zijn maar niet of relatief lastig in een unit test of een functionele test te vatten zijn.

Voor webapplicaties en websites is het in de praktijk namelijk het meest praktisch en toekomstvast om vooral te streven naar hoge code coverage met unit tests, en daarnaast vooral functionele (eindgebruikers) tests te maken waarmee je vaststelt of de geleverde functionaliteit werkt. Daarvoor kun je bijvoorbeeld selenium inzetten, en ik ben zelf wel gecharmeerd van Behat (en gebruik dat ook regelmatig) om selenium (of andere web drivers) mee aan te sturen. Je kunt ook functionele tests maken met behulp van PHPUnit, en dat is natuurlijk verwarrend, maar dat wil niet zeggen dat de tests dan ook automatisch unit tests zijn. Ik weet van vrijwel alle webplatforms dat er analoge tools beschikbaar zijn, ik weet niet precies wat je aan het bouwen bent en waarmee, maar ga vooral op onderzoek uit. If the tool fits your purpose well, you're probably doing the right thing.

---

[1] http://martinfowler.com/articles/mocksArentStubs.html

[incaz]

drm schreef op dinsdag 29 december 2015 @ 19:24:
Met andere woorden, als datgene wat hij covert stukgaat, dan moet de test falen. Je zou zeggen dat het handig is als een test zoveel mogelijk covert, maar daarmee identificeert de test ook des te minder goed wat er precies stuk is zodra dat aan de orde is.

Een heel belangrijk punt, maar je conclusie daarna is volgens mij niet helemaal juist - het gaat niet om hoe kleiner hoe beter, maar om het zoeken van de optimale verhouding, waarbij je tests fijnmazig genoeg moeten zijn om snel problemen te kunnen identificeren, maar niet per se fijnmaziger dan dat. Ook het schrijven en onderhouden van tests kost tijd, en het implementeren van mocking als je dat niet nodig hebt ook beslist.

Ik kan bv beslist niet beamen dat je voor webapplicaties beter independent unit testing kunt hebben dan integration testing. Terugkijkend denk ik namelijk dat een groot deel van de bugs die wij hadden beslist op integration-niveau lagen. Dan lijkt het me dat dat dus ook de focus van je tests moet zijn.

Bijvoorbeeld: door een applicatie heenklikken covert heel veel, maar als je foutmeldingen krijgt moet je stacktraces gaan napluizen om te zien wat er nou precies aan de hand is.

Ook dit is niet echt mijn ervaring. Die is meer dat met ergens doorheen klikken juist niet veel covert en vooral ook een hele trage manier van testen is (desondanks vaak toegepast...), terwijl het gebrek aan specificiteit meestal geen problemen opleverde. En dus zou het ook niet de specificiteit zijn die ik zou willen oplossen.

Daarom wat mij betreft de conclusie dat dit afhangt van het soort applicatie dat je aan het bouwen bent. Inderdaad: je moet weten wat je covert, maar daarna is het het kiezen van de beste coverage voor je applicatie, die met zo min mogelijk developer overhead toch voldoende fouten vangt, en voldoende informatie geeft om ze op te lossen. Maar wat 'voldoende' is, is iets dat per situatie kan verschillen.

[Megamind]

PdeBie schreef op dinsdag 29 december 2015 @ 08:27:
[...]


Stel ik heb een hele basale functie 'GetCar(int carId)'.
Dan moet ik toch kijken of deze functie het juiste object terug geeft? Daar heb je toch data voor nodig?

Dat klopt ja. Maar je test natuurlijk alleen die functie en niet de dependencies daar weer van.

Dus een GetCar functie kan misschien wel helemaal geen logica bevatten maar alleen een call naar een data laag.

Een enkele unit test kan dan ook best lang worden om alleen al alle mocks op te zetten, data te initializeren en de output te asserten.

Als voorbeeldje van een test:

C#:

        [Test]
        public void GetById()
        {
            var context = new TestContext();

            const String remoteId = "1";

            var returnObject = new EmployeeDataDto
            {
                RemoteId = remoteId,
                FirstName = "FirstName",
                LastName = "LastName",
                Email = "Email",
                IsActive = true
            };

            context.EmployeeRepository
                   .Setup(x => x.GetById(remoteId))
                   .Returns(returnObject)
                   .Verifiable();

            var result = context.EmployeeService.Get(remoteId);

            context.EmployeeRepository
                   .Verify(x => x.GetById(remoteId), Times.Once);

            Assert.AreEqual(returnObject.RemoteId, result.RemoteId);
            Assert.AreEqual(returnObject.FirstName, result.FirstName);
            Assert.AreEqual(returnObject.LastName, result.LastName);
            Assert.AreEqual(returnObject.Email, result.Email);
            Assert.AreEqual(returnObject.IsActive, result.IsActive);
        }

Daar gebruiken wij dan een testContext, die al je mockss voor je maakt:

C#:

        private class TestContext
        {
            public readonly Mock<IEmployeeRepository> EmployeeRepository = new Mock<IEmployeeRepository>();
              
            private IEmployeeService _employeeService;

            public IEmployeeService EmployeeService
            {
                get
                {
                    if (_employeeService == null)
                    {
                        _employeeService = new EmployeeService(
                            EmployeeRepository.Object);
                    }
                    return _employeeService;
                }
            }
        }

[ Voor 67% gewijzigd door Megamind op 29-12-2015 20:30 ]

[BoringDay]

roy-t schreef op maandag 14 december 2015 @ 13:30:
Voor unit tests zou je altijd vaste data moeten gebruiken. Niets is erger dan een unit test die het soms niet doet!

Voor vervelende dingen zoals databases gebruik ik zelf Effort (een in-memory database die je met 1 functie call kan reverteren naar de vorige versie).

Het zou niks mogen uitmaken of je met verschillende data werkt.
Je test is een pass of fail.
Voer je foutieve data in dan moet de test alsnog kunnen passen, door correcte fout afhandeling.

[mulder]

Als ik wil asserten of een methode het goede resultaat teruggeeft moet ik weten wat er ingaat en wat er uitgaat. Foutieve data en de daaruit volgende error asserten is een andere unit test.

[Hydra]

BoringDay schreef op zondag 03 januari 2016 @ 15:06:
Het zou niks mogen uitmaken of je met verschillende data werkt.

Hij bedoelt natuurlijk de situaties waarin je de verwachte resultaten hard-coded in je test hebt staan. Je moet altijd uit kunnen gaan van een known state. Danwel vaste data, danwel data waarvan je weet dat hij tenminste met je testcase klopt (dat je data dus niet null is voor een case die niet de null afhandeling test).

[BoringDay]

Hydra schreef op maandag 04 januari 2016 @ 11:21:
[...]


Hij bedoelt natuurlijk de situaties waarin je de verwachte resultaten hard-coded in je test hebt staan. Je moet altijd uit kunnen gaan van een known state. Danwel vaste data, danwel data waarvan je weet dat hij tenminste met je testcase klopt (dat je data dus niet null is voor een case die niet de null afhandeling test).

Hoe mijn data aangeleverd wordt vind ik minder interessant, interessant is dat mijn coverage niet verslechterd wordt en de testen slagen. In het null voorbeeld zou je dan alsnog de test kunnen laten slagen want het verwachte resultaat is dat dit een fout oplevert.

[Hydra]

BoringDay schreef op maandag 04 januari 2016 @ 15:33:
Hoe mijn data aangeleverd wordt vind ik minder interessant, interessant is dat mijn coverage niet verslechterd wordt en de testen slagen. In het null voorbeeld zou je dan alsnog de test kunnen laten slagen want het verwachte resultaat is dat dit een fout oplevert.

Dat is een andere flow als je bijvoorbeeld verwacht dat een IllegalArgumentException ofzo gegooid wordt. Dat zou je dan meestal in een andere test doen dan je 'happy flow'.