Enhetstesting i Cerebrum

Agenda

Idemyldring for enhetstesting i Cerebrum.

Idemyldring

Ein tanke tidlegare var å lage ein testdata for importane, køyre importar og deretter eksportar, og validere at dette fungerer som det skal. Er riktignok ikkje enhetstesting, men du får då testa Det Store Bildet. Enhetstesting er gjerne mangelfull, då mykje av det vi bør teste avhenger av databasetilgang.

Ei døme på dette er ei ABC-fil. Alternativt berre lage SQL direkte for å populere databasen.

Vi treng noko testdata å teste på, gjerne før vi kan enhetsteste. Ein viktig del er å teste alle spesialtilfeller, som må vere med i testgrunnlaget. Må kunne legge til nye data seinare.

Behovet for testing er ulik etter kven som tester. Utviklarar treng helst å teste API-et, medan prodsettarar treng meir å få testa komponentane.

Enhetstesting er feil namn på jobben, er gjerne "Automatisert testing", då enhetstesting er ikkje nok, treng også komponenttesting og systemtesting.

Drift sine tankar om kva som er viktig å teste:

• Testmiljøet er ofte forskjellig frå produksjonsmiljøet. Utviklarar tester i dag mot HEAD, medan prod er sjeldan i HEAD. I tillegg krever ein del av endringar tilgang til produksjonsmiljøet sin data, til dømes å snakke med FS og AD. Eksterne system kan vi ikkje få testa per i dag, vi må berre forholde oss til testmiljøa deira, der vi har det.

  Kva med staging-maskiner? Dvs. når noko er ferdig utvikla og testa mot HEAD, stager ein det og tester det mot ein kopi av prodmiljøet. Korleis kan det gjerast? Er mulig å få med Git, men kan ein kanskje skripte det også? I prodsettingsbeskrivelsen skal ein ha ei uttømmande liste over filer som skal oppdaterast. Kan legge dette til som input til eit skript som då lager ein kopi av prodmiljø og legg inn akkurat dei filene som skal oppdaterast.

  Skript:

  • Lager kopi av prod.
  • Legg inn gitte filer.
  • Lager kopi av prod-databasen.
  • Set opp miljø (pythonpath og anna)
  • Tester? Eller gjer klart for å starte testing.

• Branching: Er ønskeleg med branching, men tidlegare forsøk på branching i svn har feila.

• Cerebrum har ei utfordring med at vi har så mykje integrasjon. Avhenger av så mange andre system. I tillegg

• Cerebrum har synda i mange år med å ha lite tilpassing til enhetstesting. Til dømes vil utsendingar av e-postar vere hardkoda inn i ein metode i staden for å ha inn overhead.

• Noko anna: Vi bør standardisere på bruk av --dryrun og/eller --commit. Bør ha retningslinjer.

• Ei utfordring når ein begynner med enhetstesting er at ein kjem til å komme over masse, masse kode som krever opprydding. Er verdt å bruke tid på, fordi vi bruker i dag masse tid på å verifisere at skript ikkje gjer noko destruktivt.

• Er ønskeleg med eigne testmiljø for til dømes AD-miljø, men det er ikkje gjennomførbart. Er for mykje arbeid om vi skal drifte alle mulige, rare system vi integrerer mot. Gjerne tomme, små testmiljø.

• Overstyre metodar for testing, til dømes sendmail. Overloade metoden til ein metode som heller logger. Ein plass går grensa til kva du ikkje lenger kan teste, til dømes kan ein ikkje teste sjølve utsendinga av e-post, eller endringar i AD.

• AD-synken kan ein ikkje systemteste, så der er enhetsttestinga det einaste ein har.

• Har behov for å standardisere rammeverk, til dømes bruk av --commit og --dryrun, og bruk av testrammeverk og andre ting. Må då sette seg inn i testen før du kan begynne å teste.

• Mangler også ein kodestandard.

• Er viktig at ein held oppe trykket etter den initielle testingutviklinga. Må då kreve at ny kode skal ha enhetstestar!

• Cerebrum har gamal tankegang, og er lagd slik at populate tek seg av alt av endringar. No er det litt fugl og fisk, og seinare skript har brukke denne funksjonaliteten. Er også difor ein har affect_.

  Noko til seinare opprydding, er at ChangeLog eigentleg er to forskjellige ting, og er både for historiske data og for eventbaserte detaljar.

  Kan vurdere om populate burde gitt deg noko meir svar.

  Kva vere at list_-metodane, som vart hasteinnført utan å gjere det objektorientert, som er årsaken til at populate har forsvunne.

  Kan også bli for mykje abstrahering, til dømes DNS-modulen og studconfig.

• Med eit rammeverk på plass, kan drift gjerne lage testar sjølve. Det er dei som kjem til å ha størst behov for automatiserte testar.

• Er ønskeleg å få inn opprydding fast på planen, og ikkje berre utvikle nytt.

• Ønskeleg å ha opp lint eller pyflakes for syntaks-testing. Dette er det enighet om å sette opp allereie i dag.

• Teste GUI? Ønskeleg å få td. testa bofh-kommandoane direkte først. Er sjeldnare feil med brukargrensesnittet.