Test og kvalitetssikring

I dag er der mere og mere fokus på at ens hjemmeside er perfekt.

Med perfekt menes:

  • den er ikke nede
  • den er tilgængelig på flere enheder og platforme
  • der er ikke dele af den der ikke virker
  • alle led ned til evt. overlevering af produkter til kunden skal virke
  • kvaliteten af koden bag sitet er i orden
  • koden er til at vedligeholde og overdrage - også hvis man af grunde tvinges ud i et leverandørskifte

Altså, en lang række faktorer som enhver ejer af en hjemmeside i dag tager for givet.

Hvordan overholder vi det som leverandører ? Hvilke værktøjer har vi i kassen ?

Først og fremmest skal vi som udviklere være dovne - altså på den gode måde, vi skal være så dovne at vi ikke behøver lave noget om (fordi der er fejl i).

Hvis vi er det, så er vi allerede godt på vej. Det er bedre / dovent at bruge et kvarter mere i dag end en time på det samme om 3 måneder.

Det andet vi skal være er stolte. Hvis ikke vi er stolte af vores fag og det vi laver - hvordan skal vi så nogensinde kunne overdrage et ordentligt stykke arbejde ? Hvor mange mesterkokke ses derude der ikke er stolte af sig selv, deres fag og det de ellers står for ? Nogle gange skal vi også, som mester kokken, sige "Det er ikke sundt for dig, så det anbefaler jeg ikke du gør".

Det tredie vi skal, er at ha' en god værktøjskasse, og forstå at bruge den.

I vores verden - her hos Bellcom - der arbejder vi med PHP og JavaScript som de primære udviklings sprog. Og derfor har vi alle programmer eller IDE'er der er sat op så de understøtter så meget validering og debugging (fejlfinding) af disse sprog som muligt. Disse og andre værktøjer er beskrevet kort nedenfor.

Hvad der testes i projektet er meget specifikt pr. projekt, men hvis man skal tro Anthony Ferrara så skal der en del tests til at kunne "sove godt om natten".

Det sagt, så skal testscenarier jo ikke koste halvdelen af prodjektbeløbet.

Vi har som udgangspunkt en regl. Minimum en usecase pr. issue. - eller nærmere en usecase pr. punkt i en opgave. Og hvis ikke testen kan gennemføres når opgaven er løst, er opgaven ikke løst.

Hvis opgaven så har skiftet karakter undervejs, så skal ens usecases tilrettes, så de igen passer til opgaven.

Jeg har samlet nogen af de services vi bruger og påtænker at bruge til at gøre vi kan sove bedre om natten. Udplukket af services er ikke fyldestgørende, men dækker pænt over flere af de spillere der er på markedet.

Profiling og Debugging

Til PHP Xdebug og php-cs, Til JavaScript JSHint/JSLint. I begge tilfælde værktøjer der kan være med til at sikre kodekvalitet og finde fejl.

New Relic er en platform til at overvåge performance og finde flaskehalse i ens applikation. Den kræver dog at du har rettigheder til at installere php moduler på produktions serveren for at få udbytte af den.

Af andre værktøjer kan eks. nævnes facebook's xhprof til profiling af PHP kode.

Automatiserede tests

Tests eks. qunit til JavaScript og PHPUnit eller codeception til PHP er et kapitel for sig og CI (continuous integration) er her også en vigtig spiller.

Travis-ci er en CI service, der tilbyder at du kan kører build scripts hvergang der enten committes til en branch eller oprettes pull requests på Github. Her er der ikke tale om at de kun understøtter PHP, nej de understøtter build miljøer for en lang række sprog

Travis-ci tilbyder "PRO" konti hvis du har brug for at teste private repositories - i PRO udgaven får man også mulighed for at køre flere samtidige builds.

Et alternativ til Travis-ci er også Jenkins-ci som er en løsning du selv hoster og sætter op. Til Drupal udvikling har Reload lavet en template som gør det lettere at komme i gang her.

Kvalitetssikring

Scrutinizer er en service til at overvåge kodekvalitet og sikre at du overholder kodeguidelines og hvis ikke, så kan servicen sættes op til at rapportere "brud" direkte ind i din Github issue kø.

De har også lige annonceret at de nu understøtter "self hosted" git repositories - så eks. drupal.org kan benytte deres service direkte på modulerne. Ret lovende.

Sidste nye skud på stammen er fabbot.io rettet mod PHP og især pull requests. Denne foreslår som den eneste af de nævnte "dokumentations" rettelser til din doc-kode.