Waarom unit testen (Angular2) ?

[MrVegeta]

Ik ben bezig met een project dat al een poosje (6 maand) loopt als front-end ontwikkelaar. Er wordt gebruik gemaakt van het Angular 2 framework. Ik heb zojuist het Jasmine test framework aan de praat gekregen en het Karma test framework om de tests te draaien.

Maar ik vroeg mij af of iemand mij goed/duidelijk kon uitleggen waar unit tests precies goed voor zijn. Ik heb namelijk het gevoel dat ik een test schrijf om te zorgen dat de test het doet. Ik weet dat een unit tests isolated tests zijn waar je een functie in test, bijvoorbeeld met een verwachten. Je stopt iets in de functie en je verwacht een resultaat. Dat resultaat test je.

Waar heeft dit nou precies invloed op? Want de tests zijn geïsoleerd dus je kan niet meerdere tests aan elkaar koppelen (da's end-to-end) je kan ook niet testen of een waarde correct in de database terecht komt.

Laat ik het zo stellen, in wat voor situaties kom je er achter dat iets niet meer werkt door middel van een unit test? Gebeurd dat alleen wanneer de functie (waar een test voor geschreven is) wordt veranderd door een andere developer?

[Xanland]

Het allerlaatste wat je noemt is inderdaad één van de redenen om te unittesten. Andere zaken zijn bijvoorbeeld ook controle dat de uitkomst klopt of bijvoorbeeld om te zorgen dat een bug opgelost is.

Als de code goed geschreven is dan kan je vaak 60% of wel meer unittesten om de 'kwaliteit' van je code goed/hoog te houden. Hierdoor heb je het ook sneller door als er iets omvalt. Daarbij heb je vaak een aantal unittests per (public) method waarmee je de verschillende paden test. Extra voordeel is dat je soms ook dan makkelijker kan achterhalen waar een probleem ligt.

Nog iets anders is ook refactoring. Je weet wat je verwacht in de unittest, wat dan ook zo zou moeten blijven nadat je het gerefactored. De uitkomt is nog steeds hetzelfde, puntje is uiteraard wel dat het er aan ligt hoe je je code refactored.

Vaak zie je unittests ook opgezet worden volgens het triple A-principe: Arrange, Act en Assert.

[ Voor 22% gewijzigd door Xanland op 31-08-2017 17:02 ]

[Castor385]

Je schrijft de unit tests zodat je bij wijzigingen in de toekomst sneller kunt constateren dat er een fout is gemaakt.

Je schrijft ook unit tests om te verifieren dat de code die je schrijft ook doet wat het moet doen. In principe kun je ook de tests schrijven voordat je de code schrijft. Sommigen gaan zover dat je zelfs eerst je tests moet schrijven voordat je aan de code begint.

Ik werk zelf aan een AngularJS project met 1000-en unit tests. De keren dat het draaien van unit tests een bug in mijn verandering aantoonde is niet meer op 10 handen te tellen

[ Voor 18% gewijzigd door Castor385 op 31-08-2017 17:06 ]

[jorikdelaporik]

Je test je code om te zorgen dat het blijft werken zoals je het bedacht hebt. Een bijkomend voordeel van unit tests is dat de interface van je code meteen gedocumenteerd is.

[DixxyJS]

Ook het testen van randgevallen is een belangrijk onderdeel van de unit test.
Je wilt soms dus ook op foutieve invoer testen.

[TERW_DAN]

En je kunt in je unit-tests alle specs definiëren. Slagen al die tests, dan weet je dat je product aan alle specificaties voldoet.

Zeker als je met uitzonderingen gaat werken (en daar dan weer uitzonderingen op, die weer uitzonderingen hebben) is het handig om te weten dat je dingen niet breekt. En uitzonderingen op uitzonderingen met uitzonderingen komen nu eenmaal heel veel voor.

[MrVegeta]

@Castor385 Ik denk dat ik op zich wel fan ben van Test Driven Development. Als je eerst je test schrijft ga je goed nadenken over wat de requirements van de functie zijn en wat er bijvoorbeeld wordt doorgestuurd naar de REST laag. Daardoor ga je dus denken wat voor (input) velden zijn er nodig, welke waardes mogen deze wel/niet hebben, welke zijn verplicht om in te vullen etc.

Wij zitten met een vrij onervaren groep te werken (veel doorloop in het project, en veel junioren). Zou het voor ons dan een goed idee zijn om om tijdens scrum refinement ook unit tests gaan bespreken om zo een goed beeld te krijgen van de requirements?

Als laatst, zou je een situatie kunnen geven waarin het draaien van de unit tests een bug heeft gevonden? Dat is nog een beetje abstract voor mij.

@jorikdelaporik Met interface bedoel je wat de variabelen, functies etc zijn van de functie?(net als een Java interface)?

@DixxyJS Stel je wil een contactformulier functie. Dat heeft 3 velden: naam, telefoonnummer en email. In de unit test schrijf je dan dat de naam minimaal 1 karakter moet zijn en geen cijfers mag bevatten. Het telefoonnummer moet minimaal 10 cijfers zijn en mag enkel cijfers en het + teken bevatten en het email adres moet een geldig email adres zijn (door middel van RegEX). Als de code die je vervolgens schrijft voldoet aan de eisen van de test zou alles goed moeten werken. Is deze denkwijze goed?

@TERW_DAN Wat bedoel je met uitzonderingen? If statements?

[Dricus]

MrVegeta schreef op zondag 3 september 2017 @ 09:25:
Wij zitten met een vrij onervaren groep te werken (veel doorloop in het project, en veel junioren). Zou het voor ons dan een goed idee zijn om om tijdens scrum refinement ook unit tests gaan bespreken om zo een goed beeld te krijgen van de requirements?

De Scrum refinement sessie is volgens mij voornamelijk bedoeld om requirements van stakeholders duidelijk te krijgen, niet zozeer om het over de technische implementatie daarvan te hebben. Als je dingen als unit tests tijdens de refinement gaat bespreken dan zou hij wel eens erg lang kunnen gaan duren.

Persoonlijk zou ik er eerder voor kiezen om te pair programmen, en daarbij dan een medior/senior met een junior te laten pairen. Scheelt je weer een code review en kan voor de junior in kwestie erg leerzaam zijn (voor de medior/senior ook trouwens).

[Moi_in_actie]

MrVegeta schreef op zondag 3 september 2017 @ 09:25:
Wij zitten met een vrij onervaren groep te werken (veel doorloop in het project, en veel junioren). Zou het voor ons dan een goed idee zijn om om tijdens scrum refinement ook unit tests gaan bespreken om zo een goed beeld te krijgen van de requirements?

Ik werk in een groter SCRUM team, op een groot project met meerdere (SCRUM) teams en wij doen dat niet. Ik zie ook niet in waarom men dat zou doen. Unittesting is iets voor de developers en bij een refinement sessie zit je niet alleen met je developers, maar ook met de testers, informatie analisten, product owner(s). Die mensen zal het worst wezen hoe jullie als developers de unittests inregelen. Als developers onder elkaar, ja, bespreek het daar zeker, maar doe dit niet tijdens een refinement sessie. Het enige wat we bij ons doen op dat gebied, is bij de inschatting van werk waarbij bestaande code wijzigt, aangeven in onze motivatie dat er b.v. veel unittests bijgewerkt moeten worden.

Als laatst, zou je een situatie kunnen geven waarin het draaien van de unit tests een bug heeft gevonden? Dat is nog een beetje abstract voor mij.

Bij heel eenvoudige functies zal het niet snel voorkomen, omdat die overzichtelijk zijn. Echter, bij zeer complexe code, bijvoorbeeld iets als een rule-engine, kan je al snel door de bomen het bos niet meer zien. Diegene die de specs heeft opgesteld, een informatie-analist of iemand soortgelijks, kan natuurlijk ook fouten maken die, door de complexiteit, vooraf niet opgemerkt worden.
In zo'n situatie met iets als een rule-engine, wat in principe gewoon een aaneenschakeling van kleine beslissingen is, of bij een functie waar veel met statussen wordt gewerkt en deze (onder voorwaarde) wel of niet kunnen veranderen, kunnen best wel eens bugs ontstaan (bij het ontwerp, of tijdens het schrijven van code).
Als je met een unittest heel basaal stuk voor stuk de mogelijke uitkomsten test van zoiets, kan je best een bug vinden. Iets van "de status wordt hier OK, maar dat had vanwege eerder bepaalde status Niet OK niet meer mogen wijzigen".

De vraag is of je dat bij de front-end ook snel hebt, aangezien zulk soort code vaak dieper in een systeem zit. Wij gebruiken vrijwel geen unittests voor het voorste laagje van de front-end, daar hebben we andere tests voor (SpecFlow/CodedUI). Unittests gebruiken wij tot aan de laag erachter (WebAPI).

@TERW_DAN Wat bedoel je met uitzonderingen? If statements?

Stel een bepaald stuk code zorgt ervoor dat als alles goed gaat, er een opdracht/brief wordt verstuurd. Echter, in datzelfde stuk code zitten aanroepen naar andere functies, waarvan de uitkomst van invloed is op het wel of niet versturen van die brief. Bijvoorbeeld een aanroep naar een functie die de adresgegevens ophaalt. Worden er geen adresgegevens gevonden, dan zal je de brief nooit kunnen versturen.

[MrVegeta]

Top, bedankt voor de info. Maakt de boel een stuk duidelijker.

[Castor385]

Ik pak de unit tests mee in code reviews die we gedurende de story doen. Of bij pair programming sessies.

Ik merk dat de meesten problemen hebben met maken van mocks, met het laden van dependencies en het testen van je alleen je unit. Maar bovenal met het bedenken van de test scenario's.

TDD vind ik het makkelijkst werken bij het oplossen van bugs: je schrijft de test die de bug reproduceert. Daarna pas je de code aan, zodat alle tests weer slagen.

@MrVegeta als voorbeeld van wanneer een unit test me heeft gered: refactoring of wijzigingen in functionaliteit. Dan moet je vaak bestaande code wijzigen en de tests die ik had tonen dan snel mijn fouten aan

[TERW_DAN]

MrVegeta schreef op zondag 3 september 2017 @ 09:25:
@TERW_DAN Wat bedoel je met uitzonderingen? If statements?

Een praktijkvoorbeeld waar ik veel mee bezig ben geweest is taalanalyse. En dan heb je bijvoorbeeld zaken als lettergrepen tellen.
Je uitgangspositie is dat iedere groep klinkers 1 lettergreep is. Maar daar heb je vervolgens weer een uitzondering op, want een woord als 'cake' is maar 1 lettergreep, omdat de laatste e niet uitgesproken wordt. Dus voeg je de regel toe dat die combinatie als uitzondering gezien mag worden.
Dat werkt prima, want woorden als cakerecept en vanillecake worden ineens prima geteld.

totdat het woord electronicaketen voorbij komt, en daar klopt dan weer geen klap van. Dus zit je met een uitzondering die zelf weer een uitzondering heeft. Als je dit niet in unittests vastlegt, dan gaan heel veel dingen stuk (want zaken worden al snel complex, waardoor je als je gefocussed bent op 1 usecase, andere makkelijk uit het ook verliest, of simpelweg het bestaan niet van weet).

[Edwin88]

[b]MrVegeta schreef op zondag 3 september 2017 @ 09:25:
@DixxyJS Stel je wil een contactformulier functie. Dat heeft 3 velden: naam, telefoonnummer en email. In de unit test schrijf je dan dat de naam minimaal 1 karakter moet zijn en geen cijfers mag bevatten. Het telefoonnummer moet minimaal 10 cijfers zijn en mag enkel cijfers en het + teken bevatten en het email adres moet een geldig email adres zijn (door middel van RegEX). Als de code die je vervolgens schrijft voldoet aan de eisen van de test zou alles goed moeten werken. Is deze denkwijze goed?

Een regex voor email validatie is een slecht idee. Lees dit: https://hackernoon.com/th...il-addresses-7c4818f24643

[CH4OS]

Edwin88 schreef op vrijdag 8 september 2017 @ 10:12:
Een regex voor email validatie is een slecht idee. Lees dit: https://hackernoon.com/th...il-addresses-7c4818f24643

Ik denk ook niet dat @MrVegeta enkel en alleen een regex gebruikt voor het valideren van e-mailadressen. Valideren kan immers (wat ook in het artikel naar boven komt) enkel met een e-mail waarin een verificatie e-mail zit.

Je kunt een regex wel gebruiken, om van te voren even snel te filteren of er inderdaad een valide e-mailadres is ingevuld door forcering van een bepaalde minimale user input. Dat hoeft dan nog altijd niet te betekenen dat het bestaat, maar zo vang je in elk geval adressen waarvan je eigenlijk op voorhand al weet dat het totaal foute adressen zijn al wel af en voorkom je dat mensen bijvoorbeeld leestekens in het e-mailadres zetten die er sowieso al niet in horen.

Dat artikel vind ik dan aan de andere kant ook een beetje onzin. De tekens rondom het toetsenbord bij de L en P bijvoorbeeld, daar zitten ook leestekens tussen, maar die kun je (mits Javascript aan staat) natuurlijk ook null laten returnen als iemand een dergelijke toets indrukt. Dus ik vind sommige redenen echt een reden om een reden te kunnen hebben, maar waar prima workarounds voor zijn. Het artikel verward juist eerder dan dat het echt wat toevoegt, doordat ze twee definities van 'valide e-mailadressen' door elkaar halen en je beide vormen gewoon nodig hebt.

[ Voor 8% gewijzigd door CH4OS op 08-09-2017 15:33 ]