Un “buen” unit test cumple las siguientes reglas:

● El test sólo falla si un nuevo bug es introducido al sistema o requiere un cambio

● Cuando el test falla es fácil entender las razones de la falla.

Guideline #1: Saber qué se está probando:

Testear una cosa hace un test más fácil de leer. Cuando un test simple falla, es más
fácil encontrar la causa y arreglarlo que en un test largo y complejo.
Un truco es testear un caso y nombrar el método del test con el resultado esperado.

Guideline #2: Los unit test deben ser autosuficientes:

Un buen unit test debe estar aislado. Evitar dependencias como datos externos o
configuraciones del entorno. Un test no debería depender de correr otros test antes o del
orden de ejecución de los test. Correr el mismo test 1000 veces debe devolver el mismo
resultado cada vez.

Guideline #3: los test deben ser determinísticos:

Un test debe pasar siempre o fallar hasta ser arreglado. Un test no determinístico es
inútil ya que cuando falla, uno no puede asegurar que verdaderamente haya un bug en el
código.
Otra práctica a evitar es escribir test con datos random, ya que cuando falla, es
imposible reproducir el caso en el que falló.

Guideline #4: convención de nombre:

Para saber por qué falló un test, necesitamos entenderlo a primera vista. Lo primero
que notamos en un test es su nombre, por lo que el nombre es bastante importante.
Cuando un test con un buen nombre falla, es fácil entender qué estaba testeando y por
qué falló.

Guideline #5: repetir código

Como entender el código de forma rápida es importante en los unit test, es aceptable
repetir código.
La creación de objetos y asserts personalizados pueden ser creados para varios test si
la legibilidad del test no sufre por ello.

Guideline #6: testear resultados, no implementación

Un buen unit test sólo falla en caso de un error o porque el código requiere un cambio.
Un test frágil falla si se cambia la estructura interna del software.

Guidelines #7: evitar la sobre especificación

Evitar test controlados y estrictos que observen con precisión el flujo del programa
durante la prueba al configurar cada uno de los objetos y probar cada uno de los objetos. Esto
bloquea un escenario específico bajo prueba, evitando que cambie.
Guidelines #8: hacer test aislados
Escribir un test que requiera dependencias externas puede ser complicado, ya que
puede resultar en un test frágil que falla aunque el código esté perfecto a causa de las
configuraciones de las dependencias. Una forma de solucionar esto es utilizar librerías
externas que nos creen objetos falsos para las pruebas.