Käytä testejä näyttönä

Aloita vaatimuksesta

Testi tuottaa näyttöä tietystä väitteestä. Onnistunut testiajo ei osoita ohjelmiston kaikkia ominaisuuksia. Tunnista ennen testien pyytämistä olennainen toiminta ja virhe, jonka kunkin tarkistuksen pitää havaita.

Kuvitteellisessa organisaation tietoviennissä keskeinen vaatimus on tietojen eristys. Organisaation A käyttäjä ei saa organisaation B tietueita. Pelkkää onnistunutta latausta tarkistava testi ei osoita tätä.

Pyydä agenttia selittämään vaatimuksen ja assertionin yhteys. Puuttuvat tapaukset on helpompi havaita ennen testikokonaisuuden kasvamista.

Valitse sopiva testitaso

Unit-testi tarkistaa pienen muunnoksen nopeasti. Integraatiotesti näyttää komponenttien yhteistoimintaa. End-to-end-testi tarkistaa olennaisen käyttäjäpolun julkaistussa tai sitä vastaavassa sovelluksessa.

Valitse suppein taso, joka antaa tarvittavan näytön. Muotoilufunktion jokainen syöte ei tarvitse selaintestiä. Authorization-raja voi vaatia todellisen routen ja tietojen hakupolun. Olennainen selainvuorovaikutus tarvitsee näyttöä renderöidystä käyttöliittymästä.

Yksi testityyppien prosenttijakauma ei sovi jokaiseen järjestelmään. Valitse havaittavan virheen ja tarkistuksen ylläpitokustannuksen perusteella.

Etsi yhteinen väärä oletus

Agentti voi kirjoittaa sekä toteutuksen että testin saman väärinkäsityksen pohjalta. Ne voivat olla keskenään johdonmukaisia ja silti rikkoa vaatimusta.

Oletetaan, että toteutus suodattaa tiedot pyynnön mukana tulevalla organisaatiotunnisteella. Testissä kirjautuneen käyttäjän ja pyynnön organisaatio on sama. Testi onnistuu. Puuttuva tapaus on käyttäjä, joka pyytää toisen organisaation tunnistetta.

Lisää tämä tapaus todellisen luotetun identiteetin ja authorization-polun kautta. Aina pääsyn salliva mock ei osoita tenant-eristystä. Se kertoo vain toiminnasta onnistuneen authorizationin jälkeen.

Varmista, että testi voi epäonnistua

Aja tunnetun virheen uusi regressiotesti virheellisellä versiolla eristetyssä branchissa. Varmista, että se epäonnistuu tarkoitetusta syystä. Tee sitten korjaus ja aja testi uudelleen.

Jos testi epäonnistuu siksi, ettei fixture lataudu, se ei vielä osoita liiketoimintasäännön toimintaa. Tarkasta virhe, älä vain exit codea.

Laajemmissa muutoksissa mutation testing voi auttaa arvioimaan, havaitsevatko testit valittuja koodimuutoksia. Menetelmällä on kustannuksensa, eikä se korvaa vaatimusten tarkastusta. Käytä sitä, kun lisänäyttö auttaa olennaisessa päätöksessä.

Sido näyttö oikeaan versioon

Aja tarvittavat tarkistukset lopullisella versiolla. Kirjaa ohitetut tarkistukset ja syyt. Aiemman commitin tulos ei välttämättä päde review-korjauksen jälkeen.

Pidä testit ymmärrettävinä. Selkeä setup ja assertion ovat usein parempia kuin suuri helper, joka piilottaa olennaisen ehdon. Poista päällekkäiset tarkistukset, jos ne lisäävät ylläpitotyötä havaitsematta uutta virhetyyppiä.

Tarkastajan pitäisi osata sanoa, mitä testit osoittavat ja mikä jää epävarmaksi. Se kertoo enemmän kuin suuri testimäärä.