(Mod. siirsi projektin keskustelusta.)
– – Yksikkötestaaminen voisi auttaa muutoksessa, mutta C++:ssa ei ole siihen sopivaa standardia?
jsbasic kirjoitti:
Lisäksi yksikkötestaaminen voisi auttaa muutoksessa, mutta C++:ssa ei ole siihen sopivaa standardia?
Hyviä frameworkkejä on useita, käytän itse mm. Catch2:sta ja gtestiä. Minusta on hyvä, ettei standardiin laiteta kaikkea mahdollista.
Näköjään QtCreatorissa on testaaminen tehty helpoksi: Uusi projekti, ja sieltä Auto Test Project.
jlaire kirjoitti:
(10.02.2022 12:49:49): ”– –” Hyviä frameworkkejä on useita, käytän itse mm...
Kuinka paljon automatisoitua yksikkötestaamista ohjelmistojen kanssa oikeassa maailmassa tehdään ja onko se vaivan arvoista? Mitä se tekee koodin luettavuudelle, jos koodia kirjoitetaan yksikkötestaamisen vaatimukset edellä? Onko se oikeasti parempi ja tehokkaampi tapa kuin faktoroida koodi pieniin järkevin osiin ja testata aina koodin kirjoitusprosessin yhteydessä?
jalski kirjoitti:
Kuinka paljon automatisoitua yksikkötestaamista ohjelmistojen kanssa oikeassa maailmassa tehdään
Oman kokemukseni mukaan sitä tehdään hyvin paljon ja automaattiset (yksikkö)testit ovat osa "oikean maailman koodaamista". Paria pientä projektia epämääräisissä startupeissa lukuunottamatta olen kirjoittanut koodin ohella automaattisia testejä kaikkialla. (Lisäksi itse olin sitä mieltä, että eräs startuppi olisi hyötynyt niistä, mutta toimari kielsi.)
jalski kirjoitti:
ja onko se vaivan arvoista?
Järkevästi toteutettu automatisoitu testaus on yleensä vaivan arvoista. Olen kirjoittanut yksikkötestejä esim. joillekin putkapostikoodeilleni ja jopa codeforces-kisojen aikana kirjoitan testejä assertteina main-funktion sisälle, ettei tarvitse manuaalisesti ajaa binääriä moneen kertaan ja tarkistaa outputteja käsin.
jalski kirjoitti:
Mitä se tekee koodin luettavuudelle, jos koodia kirjoitetaan yksikkötestaamisen vaatimukset edellä?
No sitten mennään perse edellä puuhun.
Pahimmillaan merkittävä osa koodista on turhia wrappereitä ja yksikkötesteissä on niin paljon mockeja, etteivät ne testaa oikeaa toiminnallisuutta lainkaan. Jokainen koodimuutos vaatii vastaavan muutoksen yksikkötestiin. Tällaiset testit ovat hyödyttömiä ja haitallisia.
Yksikkötestauksen miettiminen voi toisaalta myös parantaa koodia. Esimerkiksi puhtaasti funktionaalisen logiikan erottaminen I/O:sta helpottaa testausta, mutta se voi tehdä toteutuksestakin selkeämmän. Lisäksi testien kirjoittaminen pakottaa miettimään heti alkuun, miten luokkaa tai funktioita tullaan käyttämään, ja tämä saattaa ehdottaa parannuksia rajapintaan. Käyn myös kaikki mieleen tulevat rajatapaukset läpi ja teen niille testit. Mahdollinen kertolaskun ylivuoto patologisilla argumenteilla jäisi muuten ehkä huomiotta.
jalski kirjoitti:
Onko se oikeasti parempi ja tehokkaampi tapa kuin faktoroida koodi pieniin järkevin osiin ja testata aina koodin kirjoitusprosessin yhteydessä?
Pieniin järkeviin osiin faktoroiminen ei ole millään tavalla ristiriidassa yksikkötestaamisen kanssa. Päin vastoin.
Jos kuitenkin testaat manuaalisesti, niin ei kai se ole iso vaiva jättää niitä testejä talteen johonkin tiedostoon, josta ne voidaan ajaa tarvittaessa uudestaan? (Ehkä jopa automaattisesti jokaisen commitin jälkeen?)
jlaire kirjoitti:
Paria pientä projektia epämääräisissä startupeissa lukuunottamatta olen kirjoittanut koodin ohella automaattisia testejä kaikkialla.
Itse en ole aikaisemmin käyttänyt yksikkötestaamista, vaikka olen kirjoittanut assertteja ja joskus hyvän tavan mukaista koodia. Nyt kun olen nähnyt miten hienosti automaatiikka toimii, aikaisempi tuntuu väärältä tavalta ohjelmoida. Ohjelman toimivuus tiivistyy jopa yhteen boolean-arvoon, joten manuaalista datan läpikäymistä ei tarvita. Siten myös inhimilliset virheet, jotka ovat merkittävä syyllinen virheisiin, vähenevät.
Qt Testissä tulostetaan linkki koodiin ja testiin käytetty suoritusaika. Qt:ssa voidaan luoda testejä taulukkomuodossa, mikä lisää luettavuutta. Ainut mikä tuossa häiritsee on tavallisen suorituksen ja autotestiprojektin erillisyys. Jos nuo olisivat samassa projektissa, main-funktioita olisi useita.
Aihe on jo aika vanha, joten et voi enää vastata siihen.