Mitä nopeammin tekoäly kirjoittaa koodia, sitä tärkeämpiä E2E-testit ovat

Vibe-koodaus – kerrot tekoälylle mitä haluat, annat sen kirjoittaa koodin ja katsot lopputulosta lähinnä tasolla "näyttääkö oikealta" – on muuttunut meemistä työtavaksi. Tuotantoon menee jo kokonaisia ominaisuuksia, joiden jokaista riviä yksikään ihminen ei ole lukenut. Kyselystä riippuen neljäsosa tai jopa puolet tekoälyä hyödyntävien yritysten uudesta tuotantokoodista on koneen kirjoittamaa.

Tuottavuushyöty on todellinen. Niin on myös kauppa, jonka hintaa harva laskee: koodin määrä kasvaa ja ihmisen katselmoinnin syvyys ohenee. Jossain kohtaa nämä käyrät leikkaavat, ja sen jälkeen laatuportti ei ole enää katselmoija. Se on se, mitä CI-putkesi oikeasti tarkistaa.

Miksi nykyiset testisi eivät riitä

"Onhan meillä testit" tarkoittaa yleensä yksikkötestejä. Tekoälyavusteisessa työtavassa niillä on ikävä sokea piste: sama malli kirjoitti ne samassa istunnossa, samalla käsityksellä tehtävästä kuin itse koodin. Jos tekoäly ymmärsi vaatimuksen väärin, testit sisältävät saman väärinymmärryksen. Ne todistavat, että toteutus on samaa mieltä itsensä kanssa – eivät sitä, että ominaisuus tekee mitä käyttäjä tarvitsee.

Tyyppijärjestelmäkään ei paikkaa aukkoa. TypeScript huomaa uudelleennimetyn kentän. Se ei huomaa, että tilauksen hintalaskenta muuttui hiljaa, että tilasiirtymä laukeaa nyt kahdesti tai että viime kuussa tallennettua dataa ei enää osata lukea.

Ja juuri saumoihin tekoälyajan regressiot kasautuvat: palvelurajapintoihin, jaettuihin kirjastoihin, tallennettuihin tietorakenteisiin. Ylläpidämme erään valmistavan teollisuuden asiakkaan tilausjärjestelmää, jossa yksi jaettu laskentakirjasto syöttää selainsovellusta, useita taustapalveluita ja vuosia sitten tallennettuja dokumentteja. Yksi itsevarman näköinen PR voi muuttaa sen, mitä tallennettu tarjous tarkoittaa – ja kaikki yksikkötestit menevät silti läpi, koska jokainen yksikkö tekee edelleen sen, minkä yksinään lupasi.

E2E-testiä ei kiinnosta, kuka koodin kirjoitti

E2E-testi ei oleta toteutuksesta mitään. Se kirjautuu sisään, rakentaa tilauksen, tarkistaa hinnan, tuottaa PDF:n ja toteaa lopputuloksen samoin sanoin kuin liiketoiminta sen toteaisi: asiakas sai oikean dokumentin.

Tätä toteutussokeutta pidettiin ennen E2E-testauksen heikkoutena – testit ovat hitaita eivätkä kerro, mikä funktio hajosi. Vibe-koodauksen maailmassa se on koko pointti. Kun toteutus on koneen tuottamaa ja kevyesti katselmoitua, ainoa kestävä määritelmä sille, että "sovellus toimii yhä", on testi, joka käyttää sovellusta kuten käyttäjä. E2E-testit ovat se määritelmä ajettavassa muodossa.

Joka PR:ssä, tai ei ollenkaan

E2E-setti, joka ajetaan öisin tai käsin ennen julkaisua, tuottaa arkeologiaa: opit että jokin hajosi, ja käytät sitten päivän selvittäessäsi, mikä eilisen kahdestatoista mergestä sen teki. Tekoälyavusteinen tiimi mergeää nopeammin kuin tuo palautesilmukka ehtii sulattaa.

Testien pitää ajautua jokaisessa pull requestissa, mergen portinvartijana. Käytännössä se vaatii, että putki pystyy käynnistämään koko sovelluspinon CI:ssä – sovellus, palvelut, tietokanta siemendatoineen – korvaamaan ulkoiset riippuvuudet kuten ERP:n ja sähköpostin stubeilla, odottamaan että kaikki on oikeasti valmiina ja ajamaan selaimen läpi kriittiset polut. Tämä on ensin infrastruktuuriprojekti ja vasta sitten testien kirjoittamista. Useimmissa auditoimissamme koodikannoissa paikallinen kehitysympäristö melkein toimii CI:ssä: reititys olettaa kehittäjän koneen, ulkoisilla palveluilla ei ole stubeja eikä mikään kerro, milloin palvelu on valmis. Tuon perustan kuntoon laittaminen on suurin osa työstä – ja se maksetaan vain kerran.

Pidä setti pienenä ja armottomana

Klassinen epäonnistuminen on tavoitella kattavuutta: satoja E2E-testejä, tuntien ajoaika ja sen verran epävakautta, että kehittäjät oppivat ajamaan punaiset buildit uudestaan lukematta niitä. Epävakaa testisetti on pahempi kuin ei settiä ollenkaan, koska se opettaa tiimin ohittamaan viimeisenkin portin.

Parempi tapa: laita ominaisuudet rehellisesti järjestykseen – liiketoiminnan tärkeyden mukaan ja sen mukaan, kuinka monen palvelun tai jaetun kirjaston kautta muutos muualla voi ne rikkoa – ja kata listan kärki. Kun teimme tämän harjoituksen hiljattain jälleenmyyntialustalle, jossa on parikymmentä erillistä ominaisuutta, koko rahavirta tiivistyi neljään käyttötapaukseen: tilauksen luonti, tuotteiden hinnoittelu, tarjous PDF:ineen sekä tilauksen lähetys ja vahvistus. Kymmenen tai viisitoista hyvin valittua polkua nappaa valtaosan katastrofeista. Loput voi jättää yksikkötesteille ja ihmisille.

Tekoälyavusteinen kehitys ei hidastu, eikä katselmoinnin pullonkaula palaa entiselleen. Vauhdin saavat pitää ne tiimit, jotka siirtävät turvaverkon muodosta "ihminen lukee diffin" muotoon "putki todistaa, että tuote toimii yhä" – jokaisessa PR:ssä, ennen mergeä.

Rebooted Solutions rakentaa automaattisia E2E-putkia CI-infrastruktuurista ja stubatuista riippuvuuksista kriittisten polkujen testisettiin asti. Jos tiiminne tuottaa tekoälyn kirjoittamaa koodia nopeammin kuin ehditte katselmoida, varaa strategiasessio – käydään läpi, miltä PR-kohtainen turvaverkko näyttäisi teidän pinossanne.