Voitot:
- Kyky estää tekoälyä hyväksymästä virheellistä käyttäytymistä "oikeana" laskemalla odotusarvo yksikkötesteissä hyväksymissäännöstä riippumatta
- Mahdollisuus tulostaa nopeita, riippumattomia ja toistettavia testejä soveltamalla AAA- ja FIRST-periaatteita ja pilkkaamalla ulkoisia riippuvuuksia
- Kyky testata testejä mutaatiolla (koodimurto) ja tunnistaa vaikeasti testattavan koodin suunnittelun hajuksi
Testauspyramidin suurin ja nopein kerros on yksikkötestaus – testaus, joka varmistaa toiminnon tai pienen koodinpalan erillään kaikesta muusta. Tuhannet yksikkötestit suoritetaan sekunneissa ja havaitsevat virheen, kun koodi on edelleen kehittäjän näytöllä. Tekoäly (AI) on ehkä taitavin yksikkötestien tuottamisessa: annat sille toiminnon, tekoäly tuottaa kymmeniä testejä. Mutta juuri tämä mukavuus synnyttää suurimman ansa: tekoäly tuottaa helposti testejä, jotka "hehkuvat vihreänä, mutta eivät vahvista mitään" tai hyväksyvät koodin nykyisen (ehkä viallisen) toiminnan "oikeana". Tässä osiossa opit kirjoittamaan todella suojaavia yksikkötestejä tekoälyllä sekä testattavan koodin ja tekoälyn välisen suhteen.
Hyvän yksikkötestin ominaisuudet: ENSIMMÄINEN
Hyvät yksikkötestit noudattavat FIRST-periaatteita: nopea, riippumaton (testit eivät saa olla riippuvaisia toisistaan), toistettava (toistettavissa - sama tulos missä tahansa ympäristössä), itsevarmentava (hyväksytty/hylätty), oikea-aikainen (ajallaan). Muistuta itseäsi näistä periaatteista, kun annat tekoälyn tuottaa testejä; pyytää erityisesti, että testi ei riipu ulkomaailmasta (todellinen tietokanta, verkko, kello) olla "riippumaton" ja "toistettavissa".
AAA-kuvio ja ilmeikäs vahvuus
Kiinteä yksikkötesti noudattaa AAA-rakennetta: Järjestä (valmistele - määritä syötteet ja riippuvuudet), Toimi (suorita - kutsu testattava funktio), Vahvista (validoi - vertaa tulosta odotettuun arvoon). Kriittinen on väittää. Yleisin tekoälyn tekemä virhe on väitteen johtaminen testattavan koodin lähdöstä - logiikka "mitä tahansa koodi palauttaa on totta". Tämä tekee testistä merkityksettömän. Oikea tapa on määrittää odotusarvo itsenäisesti (hyväksymiskriteereistä laske se manuaalisesti).
Huomio: Jos sanot tekoälylle "kirjoita testi tälle toiminnolle", tekoäly voi suorittaa toiminnon ja kirjoittaa sen tulosteen "odotetuksi". Tämä testi läpäisee, vaikka funktio olisi epätosi. Sano sen sijaan "lasket odotetut tulokset näiden sääntöjen mukaan, älä viittaa funktion nykyiseen ulostuloon."
Pilkat, tynkät ja riippuvuudet
Yksikkötestaus vaatii eristämisen. Jos toimintosi on riippuvainen tietokannasta tai API:sta, ne korvataan testauksessa valeobjekteilla (mock/stub – todellisen riippuvuuden kontrolloitu, tyhjä korvike). Tämä tekee testistä nopean, riippumattoman ja toistettavan. AI voi tuottaa valeasennusta; Mutta varo liiallista pilkkaamista: jos pilkkaat kaikkea, testi tarkistaa vain "mitä pilkka palauttaa", ei varsinaista logiikkaa. Tasapaino: jäljittele ulkomaailmaa, suorita testattava todellinen logiikka.
Testattavuus ja tekoäly
Saatiin mielenkiintoinen palaute: vaikeasti testattava koodi on usein huonosti suunniteltua koodia. Jos tekoälyllä on vaikeuksia kirjoittaa testejä funktioon (liian monta riippuvuutta, piilotettu globaali tila, sivuvaikutukset), se on suunnittelun haju. Tekoälyn kysyminen "miten muuttaisit tämän koodin testattavaksi" johtaa sekä parempaan testaukseen että parempaan koodiin.
Parametriset testit ja tiedon monimuotoisuus
Erillisen testin kirjoittaminen joka kerta saman säännön tarkistamiseksi eri syötteillä on sekä työlästä että vaikeasti ylläpidettävää. Parametrisoitu testaus – rakenne, joka suorittaa toistuvasti samaa testilogiikkaa syötteiden ja odotettujen tulosten luettelossa – eliminoi tämän toiston: yhdelle testikappaleelle syötetään kymmeniä syöttöpareja. Tekoäly on erittäin tehokas näiden syöttö-odotettujen tulostaulukoiden tuottamisessa, kun annat sille hyväksymissäännöt; Erityisesti se taulukoi järjestelmällisesti raja-arvot ja vastaavuusluokat.
Mutta tässäkin on ansa: tekoälyllä on taipumus saada odotetut tulokset luodussa taulukossa testattavasta koodista. Tämä virhe on vielä vaarallisempi parametroidussa testauksessa, koska yksittäinen virheellinen logiikka mitätöi kymmeniä rivejä. Laske siksi odotetun tuloksen sarake aina itsenäisesti hyväksymissäännön mukaisesti ja tarkista manuaalisesti vähintään muutama rivi. Pyydä myös kuvaussaraketta "mitä kukin rivi edustaa"; joten kun rivi katkeaa, näet heti, mikä tila on rikki.
Vinkki: Lisää tarkoituksella "trap rivi" parametroituun testitaulukkoon eli kirjoita tulos tietoisesti väärin. Jos tämä viiva ei muutu punaiseksi, kun suoritat testin, testi ei varsinaisesti vahvista tilannetta. Tämä on nopea valehyväksytty tarkistus.
Heikko kehote / Vahva kehote
Heikko: "Kirjoita tälle funktiolle yksikkötesti."
Vahva: Kirjoita [kieli/kehys] yksikkötestit "taxCalculate(summa, rate)" -funktiolle. Hyväksymissääntö: tulos = summa * korko, pyöristetty 2 desimaaliin; negatiivinen summa tai korko antaa virheen; palauttaa 0, jos korko on 0. Käytä AAA-rakennetta. Laske manuaalisesti odotettavissa olevat arvot NÄIDEN sääntöjen mukaan; älä viittaa nykyiseen funktion negatiivisiin tapauksiin. desimaaleihin). Kuvaa jokaisen testin sääntöä, jonka se vahvistaa.
Tehokas kehote; Se antaa hyväksymissäännön, riippumattoman odotusarvon odotuksen, rakenteen ja reunatapaukset. Siten testistä tulee säännön vartija, ei koodin peili.
Yksikkötestin laatutaulukko
oire
Huono testi (väärennetty luottamus)
hyvä testi
väittää
Ei mitään tai "ei tyhjä"
Odotettu konkreettinen arvo
Odotettu arvolähde
Toiminnon lähtö
Hyväksymissääntö / manuaalinen laskenta
riippuvuus
Todellinen tietokanta/verkko/tunti
Eristetty mock/stubilla
reunakotelo
Vain onnellinen tie
raja, negatiivinen, virhe
Kun rikot koodin
pysyy vihreänä
muuttuu punaiseksi
Nimi
testi1, testimenetelmä
kuvaa sääntöä, jonka se vahvistaa
Neljä kopioitavaa mallia
1) Sääntöihin perustuva yksikkötestaus:
Tehtäväsi: vanhempi ohjelmistotestausinsinööri.Kirjoita yksikkötesti seuraavalle funktiolle [kieli/kehys]: [allekirjoitus]. Hyväksymissäännöt: [säännöt].- Käytä AAA-rakennetta.- Laske odotusarvot manuaalisesti NÄIDEN sääntöjen mukaisesti; ÄLÄ viittaa toiminnon nykyiseen ulostuloon. - Peitä raja, negatiivinen, virhe ja onnellinen polku erillisillä testeillä. - Anna jokaisen testin nimen kuvailla sen vahvistamaa sääntöä. - Pilkkaa ulkoisia riippuvuuksia; Laita todellinen logiikka toimimaan.
2) Mutaatioresistanssin hallinta:
Tarkista nämä yksikkötestit. Listaa 5 pientä säätöä, joita voin tehdä testattavaan koodiin (a - +-merkin sijaan, >=-merkin sijaan >, rajan siirto) ja kerro minulle jokaisen kohdalla, MIKÄ näistä testeistä muuttuu punaisiksi? Jos mitään ei palauteta, testi on riittämätön. Koodi + testit: [liitä]
3) Testattavuuden tarkistus:
Miksi tälle funktiolle on vaikea kirjoittaa yksikkötestiä? Piilotettu riippuvuus, globaali asema, sivuvaikutukset, onko monia vastuita? Ehdota minimaalista refaktorointia, jotta se olisi testattavissa; älä muuta käyttäytymistä. Koodi: [liitä]
4) Epätäydellinen skenaarion valmistuminen:
Seuraavat toiminnot ja käytettävissä olevat testit on annettu. Listaa, mitä käyttäytymistä/reunakoteloa EI ole KOSKAAN testattu (scope aukko) ja lisää testi jokaiselle. Toiminto+testit: [liitä]
kolme minilaukkua
Tapaus 1 — Testaa koodin peilaus. Kehittäjä pyysi tekoälyä kirjoittamaan testin pyöristystoiminnolle; 10 testiä oli vihreitä. Itse asiassa funktio pyöristeli väärään suuntaan, mutta tekoäly oli ottanut odotetut arvot funktion lähdöstä, joten testit pitivät virhettä "tosi". Kun odotetut arvot laskettiin manuaalisesti "sääntöpohjaisella" mallilla, 4 testiä muuttui punaiseksi ja todellinen virhe paljastui.
Tapaus 2 – Mutaatiokontrollin arvo. Yksi joukkue luotti 45 yksikkötestiin. Kokeiltiin 20 pientä korjausta koodiin "mutaation kestävyyden tarkistuksella"; testeissä havaittiin vain 11 heistä. Loput 9 häiriötä sujuivat äänettömästi. Ryhmä vahvisti heikkoja testejä; Nämä parannetut testit havaitsivat todellisen laskentavirheen seuraavassa julkaisussa.
Tapaus 3 – Testaamattomuus on suunnittelun haju. Tekoäly ei voinut kirjoittaa testejä tilaustoiminnolle, se tarvitsi jatkuvasti todellista tietokantaa. "Testattavuuden tarkistus" -malli osoitti, että toiminto sisälsi pääsyn tietokantaan. Kun riippuvuusinjektio poistettiin, testit voitiin kirjoittaa ja koodista tuli puhtaampi.
Yleisiä virheitä
- Odotetun arvon johtaminen koodista. AI hyväksyy funktion ulostulon "oikeaksi"; testi, joka vahvistaa viallisen koodin.
- Testaa ilman väitettä tai triviaalilla väitteellä. "Hän ei tehnyt virhettä, hän läpäisi" logiikkaa; Se ei vahvista mitään.
- Äärimmäistä pilkkaa. Kaiken pilkkaaminen ja vain sen testaaminen, mitä pilkka antaa; todellista logiikkaa ei testata.
- Vain onnellinen tie. Ohitusraja, negatiiviset ja virhetilat.
- Ei testata rikkomalla koodia. Luotetaan vihreään tarkistamatta mutaatiota.
- Testaamattomuuden huomioiminen. Huonoa suunnittelua ei tunnisteta ja korjata sen sijaan, että pakottaisit kovan testauksen.
Yhteenvetona
Yksikkötestit ovat testauspyramidin nopein ja suurin kerros; Se huomaa virheen halvimmalla hetkellä. Tekoäly kykenee erittäin hyvin tuottamaan yksikkötestejä, mutta sen suurin sudenkuoppa on sellaisten testien kirjoittaminen, jotka olettavat virheellisen toiminnan "oikeana" johtamalla odotetun arvon itse koodista. Ratkaisu: anna hyväksymissäännöt, laske odotetut arvot manuaalisesti, pane AAA- ja FIRST-periaatteet täytäntöön, pilkkaa ulkomaailmaa ja suorita varsinainen logiikka ja testaa jokainen testi mutaatiolla (koodin rikkominen). Vaikeasti testattava koodi on suunnittelumerkki, joka vaatii korjausta.
Sovellustehtävä
Valitse omasta projektistasi liiketoimintasäännön sisältävä funktio. Kirjoita hyväksymissäännöt ja tee tekoälyn kirjoitustestit "sääntöpohjaisen yksikön testaus" -mallin avulla; Laske odotetut arvot manuaalisesti. Käytä sitten "mutaatioiden kestävyyden tarkistusta": tee vähintään 5 pientä taukoa koodiin ja mittaa kuinka moni testi muuttuu punaiseksi. Lisää uusi testi havaitsemattomille korruptioille. Ilmoita, kuinka monta häiriötä havaittiin (kuten mutaatiopisteet).
tarkistuslista
- [ ] Annoin hyväksymissäännöt ja laskin odotusarvot manuaalisesti.
- [ ] Varmistin, että testit eivät saaneet koodista odotettua arvoa.
- [ ] Olen luonut riippumattoman testauksen AAA- ja FIRST-ohjeiden mukaisesti.
- [ ] Pilkasin ulkoisia riippuvuuksia ja suoritin varsinaista logiikkaa.
- [ ] Käsittelin raja-, negatiivi- ja virhetapaukset.
- [ ] Rikkomalla koodin (mutaation) todistin, että testit todellakin suojaavat.