Testene koster mer enn de smaker? Ole Morten Amundsen

Presentasjon om: "Testene koster mer enn de smaker? Ole Morten Amundsen"— Utskrift av presentasjonen:

1 Testene koster mer enn de smaker? Ole Morten Amundsen ole.morten.amundsen@aliado.no

2 Et typisk prosjekt  Prodkode (src/main/)  Database (schema)  ORM (jpa, hibernate)  Test (src/test/)  Testdata Eks. Sak med navn  private String name;  "name" varchar2 (100)  @Column  new Sak("nn"); assertEquals("nn", sak.getName());  insert into Sak values('1','nn',..)

3 Endring av name til description er enkelt.

4 Hva med å endre relasjoner?  Prodkoden, den ekte, kjørende koden er relativt rask å endre.  (Om du følger practices som DDD, DRY og KISS) public class Vedtak{ @ManyToOne @JoinColumn(name = "SAK_ID") private Sak Sak;.. }

5 Hva med testene?  Har du mange tester? Opprettet Sak og Vedtak hundrevis av steder med new XX osv?  Har du testet mange permutasjoner? Masse insert-scripts for å teste DB, orm o.l?  Hva med integrasjonstester? FitNesse? Må disse og endres?  En slik refaktoring krever at ALT må fikses samtidig, før innsjekk.  Alt: Prodkode, orm, db OG alle tester og alle testdata.

6 Konsekvens  Tid fra utsjekk til innsjekk =.. lang  Andre kan ikke jobbe samtidig i berørt kode  Nattarbeid  Snarveier for å bli ferdig  Store feilkilder  Eller, du prøver å omgå det for unngå smerten.  Du bare jobber deg rundt og leverer story points som forventet. Applauderes for leveransedyktighet

7 JA Koster testene mer enn de smaker?  Hvorfor har vi automatiserte tester?  Høy utviklingshastighet! ??  Er nettoverdien av tester positiv? Er nettoverdien av tester positiv?

8 Hvorfor skriver vi tester?  Det jeg lager idag, skal også fungere i morgen  Kodekvalitet (TDD/BDD)  Lappverk starter så fort noen ikke tør endre eksisterende kodesnutter. Tester gir trygghet.  Felles forståelse.  Beskrivelse av oppførselen til systemet  Robust kodebase.  Redusere behov for kostbar manuell testing.  Høy utviklingshastighet, over tid (ikke bare i begynnelsen!).

9 Investér i testkvalitet!  Ut med insert-scripts! Absolutt alt, bort!  Ut med new i testene dine.  Inn med DRY, KISS, Object Mother (Builder Pattern) og/eller Factory Pattern  (Opsjon) Inn med in-memory database for testene. (f.eks hsqldb)

10 Ut med new i tester. Builder Pattern, Object Mother, Factory Pattern. @Test public void skalKunneVedtaISak(){ //factory pattern Sak sak = ObjectMother.createSak(); sak.vedta(Vedtak.GODKJENT); assertTrue(sak.hasVedtak()); } @Test(expectedException = {IllegalStateException.class}) public void enSakKanKunHaEttVedtak(){ //object mother pattern, factory pattern Sak sak = ObjectMother.createSakMedVedtak(); sak.vedta(Vedtak.GODKJENT); } @Test(expectedException = {IllegalStateException.class}) public void enSakKanKunHaEttVedtak2(){ //Builder pattern Sak sak = BuilderPattern.createSak().withVedtak(); sak.vedta(Vedtak.GODKJENT); }

11 Ut med insert scripts  Insert-scripts er kostbart vedlikehold. insert into Sak values('1','nn',..) insert into Sak values('2','nn1',..).. insert into Sak values('100','nn2',..)  Men hvordan teste db og orm uten dem?

12 @ContextConfiguration ("spring_test.xml") public class TestDBVedtakOnSak extends AbstractDbTests { @Autowired private SakService sakService; private Sak sakMedVedtak; @Before public void opprettTestData(){ sakMedVedtak = super.persist(ObjectMother.createSakMedVedtak()); } @Test public void skalKunneHenteVedtakFraEnSakIDB(){ Vedtak vedtak = sakService.hentVedtakFraSak(sakMedVedtak.getId()); assertNotNull(vedtak); } public abstract class AbstractDbTests extends AbstractTransactionalJUnit4SpringContextTests { @Repository private SakRepository repository; public Sak persist(Sak sak){ return repository.persist(sak); }

13 Databasetestdataene vedlikeholder seg selv!  Object Mother klassene er delt med resten av testene, ikke kun db-testene.  Du ser også hva som blir lagret, slik at du bedre kan teste mot det.

14 Egen erfaring: 400 tester inkl db på 15 sek, det er vel ok? Med spring, hibernate og in-memorydatabasen hsqldb Jeg deltok i gjennomføring av flere store refaktoreringer som følge av at ny informasjon kom på bordet. Raskt og robust! Testkjøring

15 Det er alltid trade-offs  Dine tester og dine builders må kontinuerlig pleies og vedlikeholdes!  Manuell testing for å dekke evt tapt insert-script testverdi  Testledere liker tester. Om flere permutasjoner:  Verdien av den enkelte test faller  Kostnaden med testvedlikehold øker  Skjæringspunktet er flyktig.  Du vil betale skyhøye renter for snarveiene dere har tatt tidligere, selv om du «måtte» for å nå en sprint-deadline.

16 Gode tester hjelper deg å være smidig! betyr alliert. Stol på oss !

17 Referanser