Prioriter testene dine! Sveinung Dalatun & Øyvind Voldsund Smidig 2011

Automatisert testprioritering I denne lyntalen skal vi snakke om automatisert testprioritering Vi tenker da på enhetstester, men kanskje enda mer relevant - (trege) integrasjonstester Vi tar for oss verktøy og teknikker som kan brukes for å få raskere feedback på testkjøringer

Problemet - Integrasjonstester Ett av problemene – og årsaken – til trege testkjøringer er trege integrasjonstester Det finnes forskjellige definisjoner på integrasjonstester, men ofte tar de gjerne lang tid å kjøre, kan ha avhengigheter til mange andre forskjellige systemer. Og dersom en integrasjonstest for eksempel bruker databaser eller konsumerer webtjenester, så kan ting begynne å ta lang tid. I tillegg har OFTE integrasjonstester større potensiale for å feile, siden de kanskje skal integreres mot andre systemer som vi selv ikke har kontroll over. http://github.com/sveinung

Problemet - Store test suites Når I tillegg prosjektet øker I omfang, og test suites blir store, og bestående av både enhets-tester, integrasjonstester, systemtester, og kanskje en del andre typer tester DA …. kan ting begynne å ta lang tid tid. For å illustrere problemet, og forklare hva vi ønsker å oppnå, så skal vi ta et enkelt eksempel http://github.com/sveinung

Her har vi et sett med tester http://github.com/sveinung

En av dissa testane inneheld en feil Som utviklere flest så er jeg lat. Jeg er utolmodig, og ønsker ikke å vente flere minutter for så å finne ut at feilen kom sist i testkjøringen. Dersom der er en feilende test, vil jeg gjerne vite det med en gang, slik at jeg kjapt kan gå i gang med å rette opp feilen. Det er vel de aller fleste enig i? Kanskje spesielt de som har søtte på et prosjekt som har pågått i årevis, og har fått en saftig kodebase med masse tester. Dersom vi hadde hatt en måte å rangere testene på, etter kor stor sannsynlighet dei har for å inneholde feil http://github.com/sveinung

1 2 3 4 … Jo da kunne vi fått den feilende testen til å kjøre først, På den måten hadde jeg fått raskere feedback, og kommet raskere tilbake til arbeidet, og vi unngår mange problem. http://github.com/sveinung

Kontekstbytte & Effektivitet Som for eksempel kontekstbytte Når man prøver å løse et problem, er det en fordel å beholde den mentale konteksten gjennom hele prosessen, sånn at man slipp å sette seg inn i problemet om og om igjen, som følge av avbrudd undervegs. En naturlig følge av kontekstbyttet er også at man blir mindre effektiv. http://github.com/sveinung

Og vi taper tid og penger vi kunne brukt på andre og bedre ting. Så ka kan vi gjer for å løse ditte problemet? Ej trur Sveinung her har et godt forslag… http://github.com/sveinung

Løsning Manuell Bruke verktøy testprioritering Det stemmer det Øyvind… For å mitigere disse problemene, kan vi gjere som følgende: Me kanprioritere testene manuelt --- f.eks ved å gruppere treige tester og kjappe tester kvar for seg (noko som i og for seg er ofte praktisert, f.eks ved å kjøre integrasjonstester for seg selv vha. Byggeverktøy som Maven) Ei anna løsning er å bruke et verktøy for å generere prioriterte testkjøringer “on-the-fly” http://github.com/sveinung

Verktøy JUnit Max 1. Power Law Distribution 2. Recent Failures For å effektivisere testkjøringer, finnes det hovedsaklig – iallefall som vi vet om – to verktøy. Junit Max som er utviklet av Kent Beck og Pritest som er utviklet av oss. Junit max er en komersiell plugin til Eclipse som prioriterer etter to faktorer: [TRYKK] Power law distribution: Kjører mange kjappe tester først, og de få treige til slutt, for å kunne få så mykje av feedbacken så tidlig som mogleg. Recent Failures: Tester som nylig har feilet, har større sannsynlighet for å feile igjen, enn tester som har kjørt grønt i lange tider. 2. Recent Failures http://github.com/sveinung

Og støtter i dag testrammeverket Junit Pritest – Hva er det? Maven plugin Junit Friprog (github) Pritest er først og fremst et system for å automatisk prioritere testane dine For øyeblikket skjer dette gjennom å kjøre testane via Maven – pluginnen blir konfigurert via pom-xml (og man velger prioriteringsteknikk) Men det er ikkje noko i vegen for å utvide støtta til andre byggeverktøy Og støtter i dag testrammeverket Junit Pritest ligger fritt tilgjengelig på github (adresse nederst til venstre på slide) http://github.com/sveinung

Prioriteringsteknikker Prioritering etter: Nylige kodeendringer Historikk fra tidligere testkjøringer Metodedekning Vi vil no ta for oss tre av teknikkane for prioritering vi har implementert i Pritest: Nylige kodeendinger Historikk fra tidligere testkjøringer OG Metodedekning http://github.com/sveinung

en endring som nettopp er gjort i koden. Nylige kodeendringer Prioriterer tester som hører til nylig endret kode Git status Den første teknikken baserer seg på at feil som oppstår, som oftest oppstår som følge av en endring som nettopp er gjort i koden. Me har implementert dette ved hjelp av Git, der tester som tilhører enten nylig tillagt kode eller modifisert kode, blir kjørt først. http://github.com/sveinung

Historikk fra tidligere testkjøringer Sorterer synkende etter antall tidligere feilinger Hver testkjøring oppdaterer en lokal database med resultater Den neste teknikken går ut i frå at tester som har vist en historisk tendens til å feile, har et større sannsyn for å feile igjen, enn tester som aldri før har feilet. Denne teknikken krever naturligvis at testresultater blir lagret for ettertida. http://github.com/sveinung

Metodedekning Prioriterer synkende etter antall dekte metoder Utviklet av Gregg Rothermel Den siste teknikken går ut i frå at tester som berører mykje av koden, har større sannsyn for å oppdage feil enn tester som berører mindre deler av koden. Teknikken prioriterer tester etter antall metodekall som er blir utført i testen. Algoritmen bak teknikken er tidligere utviklet av en amerikansk forsker som heiter Gregg Rothermel. http://github.com/sveinung

Om me då skal samanlikna dei to verktøya: Til sammenligning JUnit Max Pritest 1. Kommersielt 1. Friprog 2. Kent Beck 2. To apekattar Om me då skal samanlikna dei to verktøya: Max er kommersielt, kostar vel 100 dollar årlig, medan Pritest er fri programvare og “free as in beer” Max har sjølvaste Kent Beck bak seg, medan Pritest må klara seg med to jypplingar Og til sist: Max er ein Eclipse-plugin medan Pritest er for øyeblikket retta mot maven (dog med store planar om å erobra nytt territorium) 3. Eclipse-plugin 3. Maven-plugin http://github.com/sveinung

http://github.com/sveinung Fremtiden Produksjonssette! Generalisere Plugin for IDEA / Eclipse Nye prioriteringsteknikker Første pri for fremtida er å få produksjonssatt! Pritest er for øyeblikket ikkje kome til versjon 1.0 og kodebasen er ustabil. Prioriteringsteknikkane fungerer i stor grad som dei skal, men grunna andre begrensingar er nytten endå lita. Generalisere: støtte flere testrammeverk og VCS Vi ønsker også å lage plugins for IDEA og Eclipse Me har og planar om å legge til nye og meir effektive prioriteringsteknikker http://github.com/sveinung http://github.com/sveinung

Sveinung Dalatun & Øyvind Voldsund Konsulenter 41552866 / 92446948 sveinung.dalatun@bekk.no oyvind.voldsund@bekk.no