Codekraker 14: Jurrie Overgoor - Werkenbijtopicus
naar topicus.nl
naar topicus.nl
Codekraker 14: Jurrie Overgoor

Codekraker 14: Jurrie Overgoor

‘Met deze tool doe je het één keer fout en daarna nooit meer.’

Valideer compile time regels op je code met ArchUnit

Het schrijven van testen is groot onderdeel van het werk als software engineer. Je test de uitkomst van de code als oplossing voor een probleem. Maar niet hoe de architectuur eruit zou moeten zien. Dat wordt vaak vastgelegd in teamafspraken. Tijdens het reviewen van pull requests moeten die afspraken gecontroleerd worden. Daar is altijd de kans dat er iets doorheen glipt. Gaat er iets fout? Dan kun je de hele code langs om het probleem op te lossen. Dat is voor ons team nu verleden tijd. Met ArchUnit doe je het één keer fout en daarna nooit meer.

Werk je in teamverband dan moet je afspraken maken over de structuur en componenten van code. Hoe fijn is het als je die afspraken zelf kunt definiëren en de regels continu tijdens het bouwen gevalideerd worden? Dat kan dus met ArchUnit. Een open source Java framework die je over je eigen code heen kunt draaien. Als unit tests, dus compile time. Zelfgeschreven regels worden tijdens het bouwen tegen je code aangehouden. Je build stopt als een regel geschonden wordt. Zo voorkom je dat je een fout meerdere keren maakt.

Op de website van ArchUnit hebben ze het vooral over het testen van architectuur. Je kunt bijvoorbeeld makkelijk testen of front-end code niet direct een DAO aanroept, maar netjes via een service laag gaat. Maar met dit framework kun je zoveel meer! Je kunt juist hele obscure dingen testen. Zelf hebben wij nu 4 regels gedefinieerd. Waaronder een voor tijdreizen, om te voorkomen dat hiervoor de standaard Java new Date() gebruikt wordt. In onze code mag je die namelijk niet meer aanroepen. In plaats daarvan gebruik je de klasse MutableDate. Het aanroepen van MutableDate in plaats van new Date() is geen probleem, maar toch glipt er af en toe iets door de review heen. Automatisch kunnen testen dat àlle code MutableDate gebruikt en niet new Date() was voorheen heel lastig. Dat is wat met ArchUnit wel kan.

Verder gebruiken we ArchUnit voor het controleren..

  • ..dat er niet direct gebruik gemaakt wordt van de Java XML klasses. Deze zijn namelijk per default vatbaar voor XML External Entity Injection (XXE). In plaats daarvan moet er gebruik gemaakt worden van klasses in nl.topicus.frb.safexml.*. Die klasses lussen door naar de Java XML klasses, maar zorgen er eerst voor dat XXE niet meer mogelijk is.

  • ..of alle MDB's wel de @TransactionAttribute annotatie hebben.

  • ..of er geen @Stateful beans geïnjecteerd worden in @Stateless beans. We zien namelijk dat onze application server bij hoge load de @Stateful beans passivate. Later bij het activaten zijn de referenties naar geïnjecteerde @Stateless beans NULL. Onverklaarbare NullPointerExceptions die alleen onder hoge load af en toe optreden zijn verleden tijd.

Vaak moet je eerst tegen problemen aanlopen om erachter te komen dat je het met ArchUnit kunt oplossen. De regels die je wilt controleren moet je wel eerst zelf definiëren en schrijven. Dat vraagt om creativiteit. Maar ArchUnit heeft zoveel potentie. Het is de kunst om dat in te zien. Als je het eenmaal een keer hebt gedaan, dan pluk je voor de rest van je leven de vruchten ervan.

Benieuwd naar andere codekrakers? Check ze hier.

Jurrie Overgoor

Jurrie Overgoor

Software Engineer

mail jurrie.overgoor@topicus.nl