Alkaa tuntua siltä, että kuulun tässä asiassa ns. old school dinosauruksiin, mutta esitän hieman eriävän näkemyksen asiasta.
Lähtökohtaisesti tilanne on nähdäkseni se, että mikään (järjellinen) määrä yksikkötestejä ei sinänsä voi tyypillisessä tilanteessa taata ohjelman toiminnan oikeellisuutta. Vain poikkeustapauksissa testipatteristoista voidaan tehdä aukottoman kattavia.
Miksikö? No lähinnä siitä syystä, että esimerkiksi jo vain yhden 32-bittisen kokonaisluvun syötteeksi ottava ohjelma tarvitsee yli neljä miljardia testitapausta, jos se halutaan syötteiden osalta testata kattavasti. Joissain tilanteissa tällainen brute force -testaus on mahdollista, mutta lähes aina käytännössä syöteavaruuden kombinatorinen räjähdys kohtaa sitä, joka aikoo testata ohjelman täydellisesti.
Tästä syystä toinen keskeinen komponentti on mielestäni se, että pyritään koodia lukemalla (tai kirjoittamalla) ymmärtämään, että ollaan ratkaisemassa oikeaa ongelmaa. Kun on pyritty ensin varmistumaan logiikan oikeellisuudesta, kohtuullisella määrällä yksikkötestejä voi varmistaa, että esimerkiksi corner caseissa ei tullut söhlittyä ja saadaan jonkinlainen testipenkki, mitä vastaan samalla tavalla ajatuksella tehtyjä muutoksia voi testata.
Jos koodia ei ole edes katsottu, mennään käytännössä uskon varassa sen osalta, että koodin on edes aikomus ratkaista oikea ongelma eikä pelkästään läpäistä testitapauksia. Tähän liittyy esimerkiksi tuo aiempaan agenttien testihuijauksiin liittyvä viestini. Oleellista noissa huijaustapauksissa ei mielestäni ole se, miten ne nyt johonkin benchmarkin tuloslistaan vaikuttavat. Nuo ovat niitä asioita, jotka voivat tulla vastaan myös silloin, kun itse laatii testipenkkiä agentien tuotoksille.
Yhtenä esimerkkinä voisi nostaa tähän edeltä seuraavan:
Linkin takaa löytyi tarkempikin analyysi siitä, miltä tämä huijaus näytti:
Agentti siis rakenteli hankalassa tilanteessa ratkaisuksi kasan if-lausekkeita, jossa jokaista testicasea kohden palautettiin se vastaus, joka testicasesta piti saada ulos.
Tässä on yhdenlainen (erittäin räikeä toki) esimerkkitapaus siitä, miten pelkät yksikkötestit voi läpäistä, mutta kuitenkaan taustalla ei ole ollut edes yritystä ratkaista varsinaista ongelmaa. Helposti on kuviteltavissa vastaavanlaisia hienovaraisempia “kumilenkityksiä”, joilla läpäistään testitapauksia, mutta ei kuitenkaan ratkaista varsinaista ongelmaa. Tämä on yhdenlainen esimerkki ohjelman ylisovittumisesta testiaineistoon, mistä tuossa joku aika takaperin jotain kirjoitin.
Yksi tapa tällaisten (ainakin osittaiseen) estämiseen olisi se, että osa testitapauksista olisi sellaisia, että agenteille ei niitä koskaan näytetä, vaan ne toimivat vasta myöhemmässä vaiheessa jonkinlaisena “happotestinä” agenttituotoksen verifioinnille. Mutta tuo tietysti rikkoo sitten automaatioputken, jos koko homma oli tarkoitus automatisoida ja lopulta antaa agentille automaattista palautetta virheistä.
Agenttinen lähestymistapa on tietysti virittää sitten agentit tutkimaan agenttien tuotoksia, kuten tuossa blogikirjoituksen selvityksessä. Mutta tämäkään ei tietysti tuo itselle sitä ymmärrystä siitä, yrittääkö kirjoitettu koodi ratkaista sitä ongelmaa, jota piti olla ratkomassa. Homma lepää uskon varassa siihen, että agentit saivat keskenään homman toimimaan ja testattua.
Kuten aiemminkin olen sanonut, niin varmaan tämä johonkin hommaan sopii, mutta joissain toleranssit ovat sitten pienemmät sählingin sietämiselle. Ja itselläni kantapään kautta hankittu kokemus sotii vahvasti sitä vastaan, että käsistään voi päästään mitään, minkä toimintaa ei riittävän hyvin tunne. Historiallisesti tuommoisissa tilanteissa on varsin usein käynyt niin, että tilanteen löytää sitten edestään myöhemmin ja mahdollisesti myös vielä harmistuneen asiakkaan pelkän teknisen ongelman lisäksi.
No, mutta kuten sanottu, nämä ajatukset eivät ole nykyään oikein muodissa. 
