Unit testen van private methods in Angular

Unit testen van private methods in Angular

Dit artikel is ouder dan vier jaar. De inhoud kan verouderd zijn, vooral bij technische voorbeelden of verwijzingen naar tooling.

Het liefst test je alles binnen jouw Angular project, alleen dan weet je dat je code goed werkt na elke verandering. Binnen een component test je naast private en public attributen ook private en public methods. Public methods kun je gemakkelijk testen door in de unit test deze methods direct aan te roepen. Met verschillende parameters test je elk pad binnen deze method en weet je dat de code werkt en blijft werken.

Bij private methods is dit niet zo gemakkelijk, maar je wilt wel hetzelfde bereiken. Je hebt de methode waarschijnlijk met een reden private gemaakt, het simpelweg public maken van een method voor een unit test is `not-done` en dat wil je dus niet. Maar wat kun je wel doen?

Testen via public methods

Private methods kun je testen via public methods. Jouw private method zal waarschijnlijk door events of andere methods worden aangeroepen. Je kunt een test schrijven die zo'n event triggert of die een public method uitvoert en daarmee ook de private method uitvoert.

Verplaats logica van een method naar een service

Als jouw private method veel logica bevat (bijvoorbeeld twee if-statements of meer) kan het lastig zijn om via public methods of events alle paden van een private method te testen. Door het verplaatsen van de logica naar een service maak je jouw code beter testbaar. In plaats van dat je de directive test schrijf je een unit test voor de service die je hebt geschreven. Doordat de service public methods implementeert is de code beter toegankelijk en kun je alle testpaden beter bereiken met jouw test.

Wat als dit niet werkt

Als je niet je private methods kan testen via een public method of event, of als jouw logica niet verplaatst kan worden naar een service heb je waarschijnlijk te maken met een ander probleem:

  • De private method is code die nooit wordt gebruikt bij het uitvoeren van jouw applicatie
  • Je hebt een `design-smell`. Dit betekent dat jouw indeling van code niet ideaal is. Meestal is dit doordat jouw class te complex is opgezet/
  • Je hebt een onnodig private gemaakt.

Reacties

Er zijn nog geen reacties, laat je reactie achter.

Laat een reactie achter

Heb je een aanvulling, vraag of eigen ervaring bij dit artikel? Deel hem hieronder.

Reacties worden eerst kort gecontroleerd voordat ze zichtbaar zijn.

Bekijk alle artikelen

How to test Nuxt.js asyncData and fetch hooks

When you setup a new project with the official create-nuxt-app or when you do it manually you probably setup a testing framework to write unit tests. Most Nuxt.js and Vue applications use the official @vue/test-utils which includes clever methods and options to help you write the best unit tests for your application. You probably tried to test your asyncData or fetch hook but couldn't succeed. This article explains why this is, but also…

Continue reading

Code coverage is not a quality metric

You've just finished a new feature. The pull request is approved, the pipeline is green, and your coverage report proudly shows 100%. Great. Right? Well, not necessarily. One of the biggest misconceptions I still encounter in software teams is the belief that a high coverage percentage automatically means high quality software. It doesn't. In fact, I've seen teams proudly report 90%+ coverage while still shipping serious production…

Continue reading

Starten met unit testen in Vue

Vue wordt door steeds meer developers gebruikt. Laravel geeft out of the box de mogelijkheid om gebruik te maken van Vue en Bootstrap, maar ook React of Angular developers kiezen steeds vaker voor Vue. Na het meewerken bij een aantal projecten waar VueJS wordt ingezet begin ik te merken dat er nauwelijks wordt getest. Meest genoemde redenen zijn dat het testen te veel tijd kost en dat unit testen in de frontend moeilijk is. Volgens een…

Lees verder