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