Statisch testen? Doen!

 
28 oktober 2008

In een eerder artikel heb ik al enkele tips gegeven om betere unit testen te schrijven. Naast unit testen heeft een developer ook nog een andere vorm van testen tot zijn beschikking. Die van de statische analyse. Deze vorm van testen wordt in mijn ogen nog te weinig benut om veelgemaakte fouten uit je software te halen. Een voorbeeld:

private String string;

public void vergelijk(String s) {
if (string == s) { // doe iets}
}

Welke Java-developer heeft deze fout nog nooit gemaakt? Sterker nog, welke ervaren Java-developer heeft deze fout al tijden niet meer gemaakt? Ik verwacht niet dat er veel zijn die dat kunnen beweren.
(Voor de niet-Javanen, de fout zit in de betekenis van de equals-operator ==. Die vergelijkt alleen de referentie en niet de inhoud van de string. Voor dat laatste is de equals-methode.)

En wie heeft er niet menig uurtje zitten staren op een typefoutje als de volgende?

public void doeIets(int index) {
if(index = 1) { // doe iets }
}

Of wat te denken van het volgende?

String s = “a” + “b” + “c”;

Een constructie die door menigeen gebruikt zal worden. Toch zal dit in sommige situaties niet bepaald gewenst zijn en zou je daar liever een constructie zien die niet voor elke samenvoeging een nieuw object aanmaakt, zoals een StringBuilder of StringBuffer in Java.

Deze voorbeelden zijn slechts een kleine greep uit de vele kleine foutjes die met statische analyse uit je code gehaald kunnen worden. Tools gebaseerd op jarenlange ervaring en best practices. Tools ook die geconfigureerd kunnen worden om te controleren op dat wat je echt belangrijk vindt. Wat heb je bijvoorbeeld aan een ruleset voor I18N als de applicatie maar in 1 taal uitkomt? Of performance als je nog bezig bent om je applicatie correct te laten werken?

Voor wie de bedragen van tools als bijvoorbeeld Fortify of Coverity’s Prevent te hoog zijn, zijn er ook prima open source alternatieven. Voor Java zijn daar bijvoorbeeld CheckStyle, FindBugs of PMD; de laatste ook met copy-paste detector. C# kent onder andere Reflector.CodeMetris en FxCop. En veel andere talen kenen op z’n minst een of andere versie van de oerchecker lint.

Veel van deze tools kunnen direct door de developer gebruikt worden, via een plug-in in de IDE beschikbaar gemaakt en in de continuous build geintegreerd. Is dat allemaal nog niet genoeg, bedenk dan dat het inrichten van een static analysis tool vaak minder tijd kost, dan het vinden van een fractie van de bugs die je er mee kan oplossen. Of aan de tijd die je tijdens code reviews kwijt bent aan de triviale bugs die door deze tools gevonden hadden kunnen worden, in plaats van een review die meer op de inhoud is gericht.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development

Tags: , , , , ,


Reacties (2)

  • Just Boerlage schreef:

    Wat vooral een meerwaarde van dergelijke tooling is dat er een style conventie in opgenomen kan worden. Hierdoor dwing je programmeurs binnen een bepaald formaat/stijl te programmeren. Dit vergemakkelijkt de kennisoverdracht/leesbaarheid van de code.

    Geplaatst op 13 november 2008 om 16:17 Permalink

  • Hier staat een link van .NET Reflector:
    http://www.red-gate.com/products/reflector/video.htm

    Hier wordt een demo gegeven van .NET Reflector zodat je een indruk hebt wat .NET Reflector is en wat het kan.

    Geplaatst op 31 oktober 2008 om 9:56 Permalink