Un artículo del blog de Testing de Google, firmado por Alex Eagle, advierte sobre un patrón habitual al escribir pruebas unitarias: los llamados 'change-detector tests', tests que se limitan a verificar que el código de producción fue modificado sin evaluar realmente su comportamiento correcto. El texto parte de una situación frecuente: tras refactorizar sin alterar la lógica, decenas de pruebas empiezan a fallar y el programador dedica tiempo a aplicar cambios mecánicos en los tests, como añadir un parámetro vacío a cien llamadas.
El autor ilustra el problema con dos ejemplos de código. El primero, extremo y casi absurdo, consiste en un test que reproduce línea por línea el código de producción, a modo de checksum. El segundo, más realista, usa mocks para verificar únicamente que dos métodos colaboradores fueron invocados en orden. Aunque parece útil y rápido de escribir, este segundo test es una transformación de la misma información presente en el código de producción: cualquier cambio en la implementación lo rompe, pero no detecta defectos reales en la versión original ni en la modificada.
El artículo concluye que este tipo de pruebas ofrecen valor negativo: no atrapan errores y, además, ralentizan el desarrollo por su coste de mantenimiento. La recomendación es reescribirlas para que verifiquen comportamiento observable o, directamente, eliminarlas. El texto es una adaptación de un episodio de la serie 'Testing on the Toilet' (TotT) de Google, disponible también en versión imprimible para colocar en la oficina.