Check dit JavaScript
Jeg har ikke tal på, hvor mange gange Findbugs har reddet os fra at få sendt error-prone Java-kode ud af huset; det er utroligt rart at vide, at man har en pedantisk fætter siddende på Jenkins og overvåge éns mindste commit.
Nu begynder vi efterhånden at få en del mere JavaScript-kode i produktet også, og det har naget mit bekymrede alter ego, at denne del af koden ikke blev udsat for samme tur i vridemaskinen.
Til statisk check af JavaScript er der umiddelbart tre muligheder at vælge imellem:
Closure-compileren (der egentlig er et værktøj til optimering af JavaScript)
JSLint (som navnet antyder, inspireret af værktøjet link til checking af C-kode)
JSHint (der er en fork af JSLint)
JSHint forkede fra JSLint pga. en voldsom utilfredshed med den manglende konfigurerbarhed af JSLint; det er rart at kunne bestemme, hvor nøjeregnende checkeren skal være med visse stilistiske elementer.
Både JSLint og JSHint er skrevet i JavaScript, og kan bruges som online-værktøj, hvilket er nyttigt til at afprøve konceptet, men ikke optimalt til automatiseret test. JSHint inkluderer et “browser bundle” med en JavaScript-fil, der eksponerer en global JSHINT-funktion, som man kan kalde direkte, men der er også mulighed for at køre det som et node.js-program, eller ved brug af Rhino.
Især node-udgaven virker rigtigt nem at bruge, men da vi pt. ikke har en test-server med node har jeg indtil videre valgt at køre det på den måde, at jeg genererer en HTML-fil med JSHints browser bundle inkluderet + en CDATA-sektion, der indeholder det script, der skal checkes, og får noget JavaScript til at generere en resultatside. Dette kan så køres igennem vores sædvanlige test-framework, der loader en side op i en browser og udtrækker resultatet - her kan man f.eks. benytte PhantomJS, Selenium eller måske HtmlUnit.
Så nu har vi en JUnit-test, der knækker, hvis nogen er for sløset med semikolonerne eller andet. :-)
Det er dog ikke helt let at finde ud af at sammenstille den rette konfiguration til JSHint. En del options er dokumenteret på deres hjemmeside, men som regel når man får en warning eller error, er der inkluderet en error code (eks. “W117”), som man ikke har nogen måde at mappe til de mere generelle options (eks. “undef”). Der findes ingen dokumentation på disse error codes - andet end hvis man læser source-koden - men man kan dog i det mindste konfigurere JSHint til, at man ikke vil advares om bestemte error codes.
Optimalt set bør man sørge for, at alle dependencies er inkluderet i den kode, der checkes, så man kan benytte sig af at teste for, om man kommer til at referere til nogen udefinerede variable. Da jQuery er så udbredt, har JSHint heldigvis en option, der automatisk definerer de globals, som jQuery definerer, samt en option, der definerer det “sædvanlige” browser-miljø af indbyggede objekter.
Jeg savner dog checks for browser-inkompatibilitet - nogle af disse burde kunne findes ved statisk checking. F.eks. havde vi for nylig en bug, hvor et stykke JavaScript satte en property ved navn "new" på et objekt. Den går ikke i IE8, der ikke tillader reserverede ord som property-navne. Men den slags ups'ere fanger JSHint altså ikke.
Jeg er ikke færdig med at finde ud af, hvordan vi kan få bedre styr på vores JavaScript (tips modtages gerne), men her var da et skridt på vejen. :-)
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
