0:00:00.057,0:00:01.092
Olemme käyttäneet aikaa

0:00:01.092,0:00:03.032
muutamalla viimeisellä luennolla

0:00:03.032,0:00:05.082
keskustellen erilaisista testauksista

0:00:05.082,0:00:08.021
yksikkötestauksesta verrattuna integraatiotestaukseen

0:00:08.021,0:00:10.010
Olemme puhuneet kuinka voit käyttää RSpec:iä

0:00:10.010,0:00:12.049
todella erottelemaan koodin eri osat, joita haluat testata

0:00:12.049,0:00:14.090
olette myöskin mm. 3. kotitehtävän takia

0:00:14.090,0:00:18.017
ja muiden asioiden ohella tehneet BDD:tä,

0:00:18.017,0:00:20.062
missä olemme Cucumberin avulla kääntäneet käyttäjätarinat

0:00:20.062,0:00:22.095
integraatio ja hyväksymistesteiksi

0:00:22.095,0:00:25.061
Olette siis nähneet testausta muutamilla eri tasoilla

0:00:25.061,0:00:27.063
ja nyt tavoitteena onkin tehdä muutama tärkeä huomio

0:00:27.063,0:00:29.092
ymmärtääksemme kokonaisuuksia

0:00:29.092,0:00:33.001
ja sitoaksemme ne toisiinsa saadaksemme laajemman käsityksen

0:00:33.001,0:00:34.095
Joten tämä luento käsittelee materiaaleja

0:00:34.095,0:00:37.000
jotka kattavat kolmen tai neljän luvun asioita kirjassa

0:00:37.000,0:00:39.061
ja yritän vain tällä luennolla käydä läpi tärkeimpiä pointteja

0:00:39.061,0:00:41.046
Kysymys, joka tulee usein vastaan

0:00:41.046,0:00:43.025
Ja olen varma, että se tulee vastaan myös kaikille teistä

0:00:43.025,0:00:44.052
tehdessänne kotitehtäviänne

0:00:44.052,0:00:45.069
on: "Kuinka paljon testausta on tarpeeksi?"

0:00:45.069,0:00:48.049
Ja surullisesti, jo kauan aikaa

0:00:48.049,0:00:51.009
jos kysyit samaa kysymystä ohjelmistoalalla

0:00:51.009,0:00:52.017
vastaus oli käytännössä

0:00:52.017,0:00:53.017
"No, meillä on päivämäärä, jolloin tuotteen tulee olla valmis

0:00:53.017,0:00:54.099
joten, kuinka paljon testausta voimme tehdä

0:00:54.099,0:00:56.066
ennen sitä päivämäärää, niin paljon on tarpeeksi."

0:00:56.066,0:00:58.015
Se on se aika mitä siihen on käytettävissä.

0:00:58.015,0:01:00.002
Eli käytännössä tuo on vain epämääräinen arvio, "heitto"

0:01:00.002,0:01:01.011
joka ei ole millään tasolla hyvä.

0:01:01.011,0:01:02.054
Joten on varmasti parempiakin keinoja, eikö totta?

0:01:02.054,0:01:03.070
On olemassa jotain mitattavia asioita

0:01:03.070,0:01:06.003
kuten kuinka monta koodiriviä ohjelmalla on

0:01:06.003,0:01:08.021
ja kuinka monta koodiriviä on testejä?

0:01:08.021,0:01:10.029
Eikä ole epätavallista ohjelmistoalalla

0:01:10.029,0:01:12.068
että hyvin testatussa ohjelmistossa

0:01:12.068,0:01:14.057
testikoodin rivimäärä

0:01:14.057,0:01:17.073
on paljon suurempi kuin varsinaisen ohjelmakoodin rivimäärä

0:01:17.073,0:01:19.075
Joten jopa kokonaisluvulliset kertoimet eivät ole epätavallisia

0:01:19.075,0:01:21.084
Ja minun mielestäni jopa

0:01:21.084,0:01:23.022
opiskelu tai tutkimukseen liittyvän koodin

0:01:23.022,0:01:26.085
testauskerroin 1.5 ei ole kohtuutonta

0:01:26.085,0:01:30.005
joten siis yksi ja puoli kertaa enemmän testauskoodirivejä

0:01:30.005,0:01:32.024
kuin varsinaisen ohjelman koodirivejä

0:01:32.024,0:01:34.022
Ja useimmissa tuotantoon menevissä järjestelmissä

0:01:34.022,0:01:35.027
missä testauksella on todella merkitystä

0:01:35.027,0:01:36.091
kerroin on paljon korkeampi kuin tuo

0:01:36.091,0:01:38.015
Joten on ehkä parempi kysyä:

0:01:38.015,0:01:39.047
Enemmin kuin kysyä "Kuinka paljon testausta on tarpeeksi?"

0:01:39.047,0:01:42.049
on kysyä "Kuinka hyvää testausta olen tekemässä?"

0:01:42.049,0:01:44.035
"Kuinka perusteellista se on?"

0:01:44.035,0:01:45.056
Myöhemmin lukukaudella

0:01:45.056,0:01:46.056
Professori Sen puhuu

0:01:46.056,0:01:48.018
vähän enemmän formaaleista metodeista

0:01:48.018,0:01:50.085
ja siitä mitkä ovat testauksen ja debuggauksen rajat

0:01:50.085,0:01:52.068
Mutta muutama asia, josta voimme puhua

0:01:52.068,0:01:54.007
perustuen siihen mitä jo tiedätte

0:01:54.007,0:01:57.074
on peruskäsitteet testauksen kattavuudesta

0:01:57.074,0:01:59.054
ja sanoisin jopa

0:01:59.054,0:02:01.001
koska, tiedättehän, yleensä sanotaan, että

0:02:01.001,0:02:03.003
formaalit menetelmät eivät oikeasti toimi isoissa järjestelmissä

0:02:03.003,0:02:05.033
Minusta kyseinen toteamus

0:02:05.033,0:02:07.001
on todellisuudessa vähemmän totta kuin mitä se oli aikaisemmin

0:02:07.001,0:02:09.019
Uskon, että on olemassa useita tiettyjä alueita

0:02:09.019,0:02:10.052
varsinkin testauksessa ja debuggauksessa

0:02:10.052,0:02:12.084
missä formaalit menetelmät ovat kehittymässä valtavalla vauhdilla

0:02:12.084,0:02:15.075
ja Koushik Sen on sen alueen johtava tutkija

0:02:15.075,0:02:17.094
Joten teillä on mahdollisuus kuulla lisää siitä myöhemmin

0:02:17.094,0:02:21.043
mutta nyt, perusasioiden äärelle

0:02:21.043,0:02:22.073
puhutaan kattavuudesta ja sen mittaamisesta

0:02:22.073,0:02:24.047
koska siihen kaikki loppupeleissä perustuu

0:02:24.047,0:02:26.020
testauksen arvioinnissa

0:02:26.020,0:02:28.063
jos olet testaamassa oikeasti