DEBATT: Etter drøye 10 år med stort fokus på automatisert testing, ønsker jeg å vurdere hvor dette har tatt oss, og om omfanget av automatisert testing legges på et fornuftig nivå.

Jeg har opplevd at dette er et tema som kan være vanskelig å diskutere med mange utviklere, da det har en lei tendens til å oppstå litt «religiøsitet» hos endel. Å argumentere for mindre bruk av automatisert testing kan lett bli som å argumentere for mindre «sikkerhet» på flyplasser.

Det skal betydelig argumentasjon til for at folk vil lytte, og det er mye lettere å få gjennomslag andre veien, for folk ønsker jo sikkerhet. Men man må spørre seg om alle rutinene på dagens flyplasser gir mer sikkerhet, eller om noen av rutinene er fåfengte forsøk på å få det.

I flere anbudsforespørsler de senere årene har det vært krav om at systemet skal ha «100 prosent testdekning».

Jeg er usikker på om de som krever dette vet hva de ber om. I en bokstavelig, teknisk forstand betyr dette at hver eneste kodede funksjon og «vei» i hver enkelt funksjon skal testes at den virker som forutsatt. Man ender da raskt opp med betydelig større mengder testkode enn reell kjørekode. Det synes også implisitt forutsatt at det ikke vil være feil i testkoden…

Jeg etterlyser et mer edruelig forhold til automatiserte tester. Jeg mener testing bør holdes på et nivå hvor den gjør mer nytte enn skade.

I Ciber Norge har vi vært gjennom mange Java-prosjekter med ulik grad av automatisert testing, og brukt ulike rammeverk for dette. Eksempler er jUnit, Selenium og FitNesse, og noen prosjekter har benyttet verktøy som Cobertura for å vurdere testdekningen i prosjektet. Våre prosjekter er ofte i en mellomstørrelse, total prosjektstørrelse mellom 1 000 og 10 000 timer, og gjerne for kunder i offentlig sektor. Prosjektene våre har brukt Test Driven Development (TDD) i varierende grad. Noen prosjekter har vært utført helt uten TDD, men har valgt å skrive tester for utvalgte deler av koden i etterkant.

Hva er fordelene med automatisert testing? Jeg vil her forsøke å trekke frem de viktigste. Vær oppmerksom på at jeg ikke her fokuserer på fordeler ved bruk av TDD, da dette kan være andre.

• Man kan videreutvikle koden og være rimelig sikker på at det man gjør ikke bryter med de forutsetningene som er gjort i koden.
• Bedre støtte ved vedlikehold av koden i ettertid. Dette gir spesielt store fordeler når utviklere byttes ut.
• Man får gradvis luket ut feil ettersom man legger til nye tester når feil forekommer.
• Man kan enkelt kjøre en «suite» av tester som gjør manuell regresjonstesting mindre omfattende.
• Testene forenkler samkjøring av flere utviklere som jobber mot samme kodebase.

De fleste utviklere er enige om at automatiserte tester gir fordelene nevnt ovenfor. Men ulik bruk av automatiserte tester gir ulik grad av disse fordelene i forhold til hvor mye tid eller arbeid som legges ned i å utvikle og vedlikeholde testene.

Som i eksemplet ovenfor om sikkerhet på flyplasser, vil det alltid være mulig å legge til nye og mer omfattende rutiner for å skape sikkerhet, men på et eller annet nivå vil den økte sikkerheten ikke stå i forhold til ulempene det medfører for passasjerene å gjennomføre de aktuelle rutinene. Man kunne for eksempel nekte all form for glassprodukter eller metallbestikk etter sikkerhetskontrollen, slik at disse ikke kan benyttes til å kapre fly. Dette vil medføre betydelige problemer for restauranter og taxfreesalg, og vil neppe gi den helt store sikkerhetseffekten. Dette avspeiler seg i «Law of diminishing returns». Se illustrasjonen øverst i denne artikkelen: Kurven som viser når det er hensiktsmessig å avslutte innsatsen, fordi økt innsats ikke vil gi økt utbytte.

Det er ikke nødvendigvis slik at behovet for kontroll er det samme i alle prosjekter. Det som kan gi god og ønsket kontroll i et stort prosjekt med mange utviklere, kan være en hemsko i et mindre prosjekt med få utviklere. Et eksempel her kan være et webprosjekt med et lite og oversiktlig brukergrensesnitt som tar kort tid å teste manuelt. Hvis man i en slik situasjon benytter et webtestrammeverk for å teste frontend, kan det skape betydelige merkostnader ved videreutvikling eller modernisering, uten at testoppsettet nødvendigvis ga så mye merverdi selv når det ble satt opp første gang.

En omfattende «suite» av automatiserte tester kan også gjøre det mer arbeidskrevende å refaktorere moduler i koden.

Noen vil nok innvende at man med fornuftig strukturering av koden vil kunne kjøre de samme testene på modulen når den er ferdig refaktorert. I en ideell verden ville jeg vært enig, men ofte er årsaken til refaktoreringen nettopp at modulen eller grensesnittet til denne ikke ble strukturert og utviklet på beste vis i første runde. Full testdekning i modulen vil da gjøre refaktoreringen mer arbeidskrevende, og i mange situasjoner vil det i tillegg til refaktorering av selve koden være nødvendig med omfattende refaktorering av testkoden.

Arbeidet som utføres for å forhindre feil, i dette tilfellet automatisert testing, bør også til en viss grad ses opp mot konsekvensen av feil.

I noen prosjekter, for eksempel ved utvikling av IT-systemer for sykehusene som i verste fall kan bety liv eller død for pasientene, må man ha et annet forhold til konsekvensene av feil enn hvis man utvikler spill for barn. Jeg mener ikke å bagatellisere feil i mindre kritiske systemer, og jeg er helt innforstått med prinsipper for «craftsmanship», men det må alltid gjøres avveininger i forhold til økonomi i prosjektet eller om man skal prioritere funksjonalitet fremfor utvidet testsuite.

En innvending mot automatisert testing har vært at testene gir en slags falsk trygghet for de som skal videreutvikle koden. Dette er mulig, uten at jeg har sett klare tegn til det.

Uansett er det en forutsetning at de som skal videreutvikle koden har full forståelse for hvordan koden henger sammen. En solid testsuite kan gi en god «dokumentasjon» av koden, slik at det er lettere å få forstå hvordan den er ment å virke. En middels god eller utdatert testsuite kan skape mer forvirring enn oversikt. Man må derfor være klar over at testene og mockede objekter må videreutvikles i parallell med koden. En slurvet holdning her vil fort føre til at testsuiten forvirrer mer enn den hjelper.

Kvaliteten på testkoden er like viktig som kvaliteten på kjørekoden.

Jeg har sett eksempler på at man for å kunne teste deler av koden, åpner opp koden mer enn man ellers ville gjort. I slike tilfeller fører testingen til at man har mindre kontroll enn man ville hatt uten testene. Kvalitetssikring av testkoden er altså viktig, og må ikke nedvurderes i forhold til kvalitetssikring av kjørekoden.

Finnes det noe alternativ til automatisert testing? Nei, ikke noe som oppnår helt det samme, men det er fremdeles mulig å benytte mange kjente, kjære teknikker og prinsipper for å utvikle kode som har liten sannsynlighet for feil. I endel tilfeller vil dette være godt nok, i hvert fall på deler av koden.

Hva er så et fornuftig nivå for automatisert testing?

Som nevnt er dette avhengig av systemet som skal utvikles, dets størrelse og i hvilken grad konsekvensen av feil er kritisk. Hvis man forutsetter at prosjektet skal utvikle et system som ikke dreier seg om liv og død ved feil, og er i en størrelsesorden 5 000 til 10 000 timer, vil jeg anbefale følgende strategi for (automatisert) testing og kvalitet:

• Legg forretningslogikken i modellen, og test denne.

Sørg for at så mye som overhodet mulig av forretningslogikken ligger i domenemodellen. Ha denne som en separat del av koden (for eksempel som eget prosjekt i utviklingsverktøyet). Etterstreb høy testdekning (med jUnit eller lignende) av den viktige koden i denne delen av systemet (det vil si ikke test «gettere og settere» og slikt, men der hvor det finnes kode med risiko for feil).

• Trekk ut generelle funksjoner, og test disse.

Sørg for at alle funksjoner som kan generaliseres på fornuftig vis, blir generalisert, og at resten av koden benytter denne mer generelle koden. Hvis du så sørger for at denne koden blir testet, unngår du mange feil uten å utforme mengder av testkode.

• Bruk «Single Responsibility Principle», og lukk koden.

Strukturer koden din slik at klassene i så stor grad som mulig har et rent og oversiktlig grensesnitt mot resten av applikasjonen. Sørg for å beskytte klassevariable for påvirkning utenfra. Hvis det er vanskelig å teste all funksjonaliteten i klassen uten å åpne opp med ekstra metoder eller å gjøre klassevariable tilgjengelige utenfra, er det ofte et tegn på at det kan være fornuftig å omstrukturere klassen til mindre klasser.

• Gjør det lett å finne ut hva en feil kommer av.

Sørg for nullsjekking av parametere, slik at man lett kan identifisere hva som forårsaker feil. Hvis du er i tvil om en feilsituasjon noengang vil oppstå, og om du trenger å ta hensyn til den, kast alltid en exception som beskriver hva som har skjedd.

• Kvalitetssikre all testkode på samme nivå som kjørekoden.
• Vurder om enkelte deler av applikasjonen er godt nok testet.

I mange applikasjoner er det funksjoner som er kritisk i sin natur. I en nettbutikk er det for eksempel kritisk å ha på plass rutiner som sørger for at ikke priser er null eller betydelig lavere enn det korrekte tallet. Vurder om det finnes slike caser i din applikasjon, og om det trengs ekstra rutiner som forhindrer slike feil.

Jeg mener man ved en slik tankegang vil kunne utvikle systemer som er rimeligere, og hvor automatisk testing står i et fornuftig forhold til systemets behov.

Anonyme kilder med angivelig kjennskap til Microsofts planer for Wndows Phone 8.1 forteller til The Verge at den kommende oppdateringen vil inkludere funksjonalitet som bringer systemet mer opp på høyde med Android og iOS når det gjelder funksjonalitet.

Det ene er en Siri-lignende personlig assistent med kodenavnet Cortana. Navnet stammer forøvrig fra spillet Halo, i likhet med Threshold-navnet som trolig refererer til en framtidig bølge med Windows-oppdateringer. I Halo er Cortana en rollefigur med kunstig intelligens som kan lære og tilpasse seg. Cortona er altså et ganske passende navn på denne kommende funksjonen.

Ryktet om Cortana er forøvrig ikke helt nytt.

Siri kom til iOS i 2011. Googles variant, Google Now, kom nesten et år senere. De har sine ulike styrker og svakheter, men regnes for tiden som omtrent like gode og betydelig bedre enn for et år siden. Google Now tilbys forøvrig også til iOS.

Den andre store nyheten som trolig kan ventes i Windows Phone 8.1, er et varslingssenter som kan dras ned fra toppen av skjermen, slik man lenge har kunnet i Android og senere også i iOS. Her vises varslene fra både operativsystemet og de ulike applikasjonene på ett og samme sted.

Andre nyheter som ifølge disse kildene kan ventes i den kommende oppdateringen, er separate kontroller for lydstyrken til ulike funksjoner, for eksempel ringetonen og medieavspillingen. Det antydes også at Bing Smart Search vil komme på plass, slik det er i Windows 8.1. Dessuten skal det innebygde musikknavet erstattes med separate apper.

Alt tyder på at Windows Phone 8.1 vil bli gitt ut i tidsrommet rundt Microsofts kommende Build-konferanse, som arrangeres i San Francisco i april.

Ifølge Georgia Institute of Technology, også kjent som Georgia Tech, er det en virkelig stor utfordring knyttet til nanomaskiner – virkelig små datamaskiner egnet for å utføre enkle oppgaver, for eksempel å overvåke og utveksle sensordata – nemlig antennen.

Dersom også antennen lages i nanometerstørrelse og i kobber, vil radiosignalene måtte ha en frekvens på hundrevis av terahertz. Med så høye frekvenser har signalene bare noen få mikrometer. I tillegg kreves det mye effekt, noe nanomaskiner sjelden vil kunne levere, siden noe av målet er at de skal kunne kjøre på energi hentet fra omgivelsene.

Alternativet er større antenner, men da vil antennene være langt større enn datamaskinene, og dermed forsvinner mye av vitsen.

Grafén
Men nå kan forskere ved Georgia Tech ha funnet en løsning basert på «vidundermaterialet» grafén, som har en rekke svært interessante egenskaper. Grafén består av et lag med karbonatomer som danner et bikake-lignende gitter. Dette kan danne en elektrisk overflatebølge som gjør det mulig å lage antenner som bare er 1 mikrometer lange og 10 til 100 nanometer brede, og som kan gjøre den samme jobben som mye større antenner.

Til tross for størrelsen mener forskerne at den vil kunne operere i den nedre enden av terahertz-området, mellom 0,1 og 10 terahertz.

Dette oppnås ved hjelp av det som kalles for en SPP-bølge (Surface Plasmon Polariton).

– Når elektroner i grafénet blir eksitert av for eksempel en innkommende, elektromagnetisk bølge, begynner å de å bevege seg fram og tilbake. På grunn av de unike egenskapene til grafén, resulterer denne globale oscilleringen av elektrisk ladning i en avgrenset bølge på toppen av grafénlaget, forteller Ian Akyildiz, professor i telekommunikasjon ved Georgia Techs School of Electrical and Computer Engineering, i en pressemelding.

Forplantning av SPP-bølger er ikke noe unikt ved grafén. Det kan også støttes av en del edle metaller, slik som gull og sølv, men ifølge Georgia Tech skjer dette ved langt høyere frekvenser enn det som man mener er tilfellet med grafén. For det er nemlig ikke slik at forskerne har demonstrert dette ennå. Antagelsen er basert på modellering og simulering.

Forskerne er likevel svært optimistiske når det gjelder mulighetene disse egenskapene kan bidra til. I pressemeldingen opplyses det at effektbehovet kan reduseres med fire størrelseordener i forhold til kobberbaserte antenner. Men det sies ingen ting om rekkevidden, selv om reduksjon av frekvensen med 99 prosent nok betyr ganske mye.

– Vi tror at dette bare er begynnelsen på en nytt paradigme for nettverk og kommunikasjon basert på grafén, sier Akyildiz.

Science fiction?
Dette handler ikke bare om kommunikasjon internt i et nettverk av nanodatamaskiner. Man ser nemlig også for seg at samlinger med hundre- eller tusenvis av knøttsmå transceivere, utstyrt med grafénantenner, kan gi mer tradisjonelle datamaskiner mer trådløs båndbredde.

– Terahertz-båndet kan øke dagens datarater i trådløse nettverk med mer enn to størrelsesordner. Dataratene i dagens mobilsystemer er på opptil én gigabit per sekund i LTE Advanced-nettverk og 10 gigabyte per sekund i såkalte millimeter-bølge- eller 60 gigahertz-systemer. Vi venter datarater i terabit per sekund-størrelsen i terahertz-båndet, sier Akyildiz.

Nøyaktig hvordan dette er tenkt å fungere, er ikke oppgitt, men omtales kanskje i en vitenskapelig artikkel om forskningen som er planlagt publisert i IEEE Journal of Selected Areas in Communications.

Neste mål for forskerne vil være å lage en faktisk nanoantenne i grafén og bruke den sammen med en transceiver som også er laget av grafén.