12.1.1. El nombre del test no es suficientemente descriptivo
Recordemos que el nombre de un método y de sus parámetros son su mejor documentación. En el caso de un test, su nombre debe expresar con total claridad la intención del mismo.
12.1.2. No sabemos qué es lo que queremos que haga el SUT
Nos hemos lanzado a escribir un test pero no sabemos en realidad qué es lo que el código bajo prueba tiene que hacer. En algunas ocasiones, lo resolvemos hablando con el dueño de producto y, en otras, hablando con otros desarrolladores. Tenga en cuenta que está tomando decisiones de diseño al escribir el test y que la programación por parejas o las revisiones de código nos ayudan en la toma de decisiones.
12.1.3. No sabemos quién es el SUT y quién es el colaborador
En los tests de validación de interacción, pensamos que el colaborador, aquel que representamos mediante un doble, es el SUT. Antes de utilizar dobles de prueba tenemos que estar completamente seguros de quién es el SUT y quién es el colaborador y qué es lo que queremos comprobar. En general, comprobamos que el SUT habla con el colaborador, o bien le decimos al colaborador que, si le hablan, responda algo que le decimos.
12.1.4. Un mismo método de test está haciendo múltiples afirmaciones
Cuando practicamos TDD correctamente, apenas tenemos que usar el depurador. Cuando un test falla, lo encontramos directamente y lo corregimos en dos minutos. Para que esto sea así, cada método debe probar una única funcionalidad del SUT. A veces utilizamos varias afirmaciones (asserts) en el mismo test, pero sólo si giran en torno a la misma funcionalidad. Un método de test raramente excede las 10 líneas de código.
12.1.5. Los test unitarios no están separados de los de integración
Los tests unitarios se ejecutan frecuentemente. De hecho, se ejecutan continuamente cuando practicamos TDD. Así que tenemos que conseguir que se ejecuten en menos de un segundo. Esta es la razón fundamental para tenerlos separados de los tests de integración
12.1.6. Rápido, Inocuo, Atómico, Independiente
Si rompe alguna de sus propiedades, entonces no es un test unitario. Pregúntese si sus tests cumplen las reglas y, en caso de que no sea así, piense si con un poco más de esfuerzo puede conseguir que lo hagan.
12.1.7. Se nos olvida refactorizar
No sólo por tener una gran batería de tests, el código ya es más fácil de mantener. Si el código no está limpio, será muy costoso modificarlo, y también sus tests. No olvide buscar y corregir código duplicado después de hacer pasar cada test. El código de los tests debe estar tan limpio como el código de producción.
12.1.8. Confundir un mock con un stub
Cuando queremos que un objeto falso devuelva una respuesta programada en caso de que se le llame, usamos un stub. Cuando queremos confirmar que efectivamente la llamada a un método se produce, usamos un mock. Un mock es más restrictivo que un stub y puede aumentar la fragilidad del test. No obstante, en muchas ocasiones la mejor solución pasa por usar un mock.
12.1.9. No eliminamos código muerto
A veces, tras cambios en la lógica de negocio, queda código en desuso. Puede ser código de producción o pueden ser tests. Puesto que disponemos de un sistema de control de versiones que nos permite volver atrás si alguna vez volviese a hacer falta el código, debemos eliminarlo de la versión en producción. El código muerto induce a errores antes o después. Se suele menospreciar cuando se trata de tests pero, como ha visto, el código de los tests es tan importante como el código que prueban.