Olemme käyttäneet aikaa muutamalla viimeisellä luennolla keskustellen erilaisista testauksista yksikkötestauksesta verrattuna integraatiotestaukseen Olemme puhuneet kuinka voit käyttää RSpec:iä todella erottelemaan koodin eri osat, joita haluat testata olette myöskin mm. 3. kotitehtävän takia ja muiden asioiden ohella tehneet BDD:tä, missä olemme Cucumberin avulla kääntäneet käyttäjätarinat integraatio ja hyväksymistesteiksi Olette siis nähneet testausta muutamilla eri tasoilla ja nyt tavoitteena onkin tehdä muutama tärkeä huomio ymmärtääksemme kokonaisuuksia ja sitoaksemme ne toisiinsa saadaksemme laajemman käsityksen Joten tämä luento käsittelee materiaaleja jotka kattavat kolmen tai neljän luvun asioita kirjassa ja yritän vain tällä luennolla käydä läpi tärkeimpiä pointteja Kysymys, joka tulee usein vastaan Ja olen varma, että se tulee vastaan myös kaikille teistä tehdessänne kotitehtäviänne on: "Kuinka paljon testausta on tarpeeksi?" Ja surullisesti, jo kauan aikaa jos kysyit samaa kysymystä ohjelmistoalalla vastaus oli käytännössä "No, meillä on päivämäärä, jolloin tuotteen tulee olla valmis joten, kuinka paljon testausta voimme tehdä ennen sitä päivämäärää, niin paljon on tarpeeksi." Se on se aika mitä siihen on käytettävissä. Eli käytännössä tuo on vain epämääräinen arvio, "heitto" joka ei ole millään tasolla hyvä. Joten on varmasti parempiakin keinoja, eikö totta? On olemassa jotain mitattavia asioita kuten kuinka monta koodiriviä ohjelmalla on ja kuinka monta koodiriviä on testejä? Eikä ole epätavallista ohjelmistoalalla että hyvin testatussa ohjelmistossa testikoodin rivimäärä on paljon suurempi kuin varsinaisen ohjelmakoodin rivimäärä Joten jopa kokonaisluvulliset kertoimet eivät ole epätavallisia Ja minun mielestäni jopa opiskelu tai tutkimukseen liittyvän koodin testauskerroin 1.5 ei ole kohtuutonta joten siis yksi ja puoli kertaa enemmän testauskoodirivejä kuin varsinaisen ohjelman koodirivejä Ja useimmissa tuotantoon menevissä järjestelmissä missä testauksella on todella merkitystä kerroin on paljon korkeampi kuin tuo Joten on ehkä parempi kysyä: Enemmin kuin kysyä "Kuinka paljon testausta on tarpeeksi?" on kysyä "Kuinka hyvää testausta olen tekemässä?" "Kuinka perusteellista se on?" Myöhemmin lukukaudella Professori Sen puhuu vähän enemmän formaaleista metodeista ja siitä mitkä ovat testauksen ja debuggauksen rajat Mutta muutama asia, josta voimme puhua perustuen siihen mitä jo tiedätte on peruskäsitteet testauksen kattavuudesta ja sanoisin jopa koska, tiedättehän, yleensä sanotaan, että formaalit menetelmät eivät oikeasti toimi isoissa järjestelmissä Minusta kyseinen toteamus on todellisuudessa vähemmän totta kuin mitä se oli aikaisemmin Uskon, että on olemassa useita tiettyjä alueita varsinkin testauksessa ja debuggauksessa missä formaalit menetelmät ovat kehittymässä valtavalla vauhdilla ja Koushik Sen on sen alueen johtava tutkija Joten teillä on mahdollisuus kuulla lisää siitä myöhemmin mutta nyt, perusasioiden äärelle puhutaan kattavuudesta ja sen mittaamisesta koska siihen kaikki loppupeleissä perustuu testauksen arvioinnissa jos olet testaamassa oikeasti