Testene koster mer enn de smaker? Ole Morten Amundsen

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)  new Sak("nn"); assertEquals("nn", sak.getName());  insert into Sak values('1','nn',..)

Endring av name til description er enkelt.

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 = "SAK_ID") private Sak Sak;.. }

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.

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

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?

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!).

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)

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

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?

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

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.

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

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.

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

Referanser