Una **asserció** (assertion) és la comprovació que fa fallar la prova quan la condició no es compleix. Una prova pot acabar de tres maneres: passa, **falla** perquè una asserció no s'ha complert, o dona **error** perquè ha saltat una excepció que ningú esperava.
### Quins casos provar
Cap suite no pot provar totes les entrades possibles, així que provar és triar. Els casos d'una funcionalitat es reparteixen en tres grups:
-**Camí feliç** (happy path): l'ús previst, amb dades vàlides i sense res que vagi malament. Retirar 30 d'un compte amb 100.
-**Casos límit** (edge cases): les entrades a la vora d'un canvi de comportament, que és on s'amaguen la major part dels errors. Retirar exactament 100, retirar 0, retirar el valor màxim d'un `int`.
-**Casos d'error**: les entrades que el codi ha de rebutjar, i la manera com les rebutja. Retirar 150 d'un compte amb 100, o una quantitat negativa.
El camí feliç és el que tothom escriu i el que menys informació dona, perquè és el cas que qui programava ja tenia al cap. Els altres dos són els que troben els bugs.
Per trobar els límits sense endevinar-los, es parteix el domini de cada entrada en classes que haurien de comportar-se igual (**particions d'equivalència**) i es prova un valor de cada classe més els que hi ha just a banda i banda de cada frontera (**anàlisi de valors límit**). Per a `withdraw`, les classes són quantitat negativa, zero, entre zero i el saldo, i per sobre del saldo; les fronteres són el zero i el saldo exacte.
### Com anomenar una prova
El nom d'una prova és el que llegeixes quan falla al pipeline, sovint sense el codi al davant. Compara aquests dos:
@@ -233,7 +245,9 @@ Si a la passa 2 continua verda, la prova no travessa el camí que et penses, o l
Quan el que fas és arreglar un bug no cal sabotejar res: escriu la prova abans de la correcció i el vermell te'l dona el bug, com ja hem vist a les [proves de regressió](#proves-de-regressió).
**Deriva els casos del requisit, no de la implementació.** Llegir el codi línia a línia per decidir què provar té dos efectes: copies el comportament que hi ha en lloc del que hi hauria d'haver, i només cobreixes el camí feliç. La branca que falta és invisible precisament perquè falta, i cap lectura del codi te la mostrarà. Els casos límit i d'error surten del requisit, no del `if` que tens al davant.
**El resultat esperat surt del requisit, no del codi.** Llegir el codi línia a línia per decidir què provar té dos efectes: copies el comportament que hi ha en lloc del que hi hauria d'haver, i només cobreixes el [camí feliç](#quins-casos-provar). La branca que falta és invisible precisament perquè falta, i cap lectura del codi te la mostrarà. Els casos límit i d'error surten del requisit, no del `if` que tens al davant.
El que no pot sortir del codi és el **resultat esperat**. Escollir quins casos exercites és una altra decisió, i aquí mirar la implementació és legítim i de vegades imprescindible: una branca que la [cobertura](#cobertura) marca com a no executada, un [mutant](#testing-de-mutacions) que ha sobreviscut, unes claus que col·lideixen a propòsit per veure si una taula de hash degenera, o l'entrellaçat de fils que només saps que existeix perquè has vist on és l'estat compartit. En tots aquests casos el codi et diu on buscar i el requisit continua dient què ha de passar.
El senyal d'alerta és fàcil de reconèixer: si escrius les proves d'un codi ja fet i totes passen a la primera, no has verificat res, has fotografiat el comportament actual.
