Utilitzeu les proves com a evidències

Comenceu pel requisit

Les proves aporten evidències per a afirmacions concretes. Una execució satisfactòria de les proves no acredita totes les propietats del programari. Abans de demanar proves, identifiqueu el comportament important i el defecte que ha de detectar cada comprovació.

En una exportació fictícia de dades d’una organització, el requisit principal és l’aïllament de dades. Un usuari de l’organització A no ha de rebre registres de l’organització B. Una prova que només comprova una descàrrega satisfactòria no acredita aquest requisit.

Demaneu a l’agent que expliqui la relació entre el requisit i l’asserció. Això facilita la detecció dels casos que falten abans que el conjunt de proves creixi.

Trieu l’abast de prova adequat

Una prova unitària pot comprovar ràpidament una transformació petita. Una prova d’integració pot comprovar com funcionen junts els components. Una prova d’extrem a extrem pot comprovar una seqüència important d’accions de l’usuari a través de l’aplicació desplegada o d’una de representativa.

Utilitzeu l’abast més reduït que proporcioni les evidències necessàries. Un formatador no necessita una prova completa de navegador per a cada entrada. Un límit d’autorització pot necessitar una ruta real i un recorregut real d’accés a dades. Una interacció crítica al navegador necessita evidències sobre la interfície renderitzada.

Cap percentatge fix de tipus de proves no serveix per a tots els sistemes. Trieu-los segons la fallada que necessiteu detectar i el cost de mantenir la comprovació.

Eviteu una hipòtesi incorrecta compartida

Un agent pot escriure la implementació i les proves a partir del mateix malentès. Totes dues poden concordar mentre el requisit continua sense complir-se.

Suposeu que la implementació filtra registres per l’identificador d’organització proporcionat a la petició. La prova utilitza el mateix identificador per a l’usuari que ha iniciat sessió i per a la petició. La prova passa. El cas que falta és el d’un usuari que demana l’identificador d’una altra organització.

Afegiu aquest cas a través del recorregut real d’identitat fiable i autorització. Un mock que sempre retorna «permès» no pot acreditar l’aïllament entre tenants. Només acredita el comportament posterior a una autorització satisfactòria.

Verifiqueu que la prova pot fallar

Per a un defecte conegut, executeu la prova de regressió nova contra la versió defectuosa en una branca aïllada. Confirmeu que falla pel motiu previst. Després apliqueu la correcció i torneu-la a executar.

Una prova que falla perquè no es poden carregar les dades de prova encara no aporta evidències sobre el comportament de negoci. Inspeccioneu la fallada, no només el codi de sortida.

En canvis més amplis, les proves de mutació poden ajudar a avaluar si determinats canvis de codi provoquen fallades de les proves. Tenen un cost i no substitueixen la revisió dels requisits. Utilitzeu-les quan les evidències addicionals donin suport a una decisió amb conseqüències importants.

Manteniu les evidències vinculades al canvi

Executeu les comprovacions pertinents sobre la revisió final. Registreu les comprovacions omeses i els motius. Un resultat d’un commit anterior pot deixar de ser aplicable després d’una correcció de revisió.

Manteniu les proves entenedores. Preferiu una preparació i una asserció explícites a una gran funció auxiliar que amagui la condició important. Elimineu les comprovacions redundants quan afegeixin cost de manteniment sense detectar una fallada diferent.

Qui revisa el canvi ha de poder indicar què acrediten les proves i què continua sent incert. Aquesta explicació és més útil que un gran nombre de proves.