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

Security by design in Angular

Security by design in Angular

A route guard and a green pipeline do not stop one customer reading another customer's invoice. Using Angular and a .NET API, I turn a security requirement into server-side ownership checks and tests. Security by design starts with boundaries and evidence, before choosing a scanner.

Continue reading

How to test Nuxt.js asyncData and fetch hooks

Nuxt's asyncData and fetch hooks need a different testing approach from ordinary Vue component methods. This article demonstrates calling hooks directly and supplying their context explicitly. It also draws the boundary around those tests: checking a hook's logic is useful, but it does not prove that Nuxt invokes it correctly during navigation or rendering.

Continue reading

The bullshit of code coverage

A test suite can reach 100% coverage and still charge the wrong shipping fee or take a payment twice. Through boundary cases, misleading mocks and missing requirements, I examine what coverage actually proves. The useful question is not whether the code ran, but whether the tests would catch the mistakes your customers care about.

Continue reading