Estoy leyendo El arte de las pruebas unitarias de Roy Osherove. Estoy en la sección 7.2 Escribiendo pruebas mantenibles donde el autor tiene esta nota sobre el olor del código:
NOTA: Cuando refactoriza el estado interno para que sea visible para una prueba externa, ¿podría considerarse un olor a código (una señal de que algo podría estar mal en el diseño o la lógica del código)? No es un olor a código cuando refactoriza para exponer a los colaboradores. Es un olor a código si está refactorizando y no hay colaboradores (por lo que no necesita tropezar ni burlarse de nada).
EDITAR : Lo que el autor quiere decir con "colaboradores" son dependencias. Algunos de sus ejemplos de dependencias son clases que acceden a una base de datos o que acceden al sistema de archivos del sistema operativo. Aquí es donde define el trozo y comienza a usar la palabra colaborador:
Un stub es un reemplazo controlable para una dependencia existente (o colaborador ) en el sistema.
El autor no tiene un ejemplo de este olor a código y estoy teniendo problemas para entender / imaginar cómo se vería. ¿Alguien puede explicar esto un poco más y tal vez proporcionar un ejemplo concreto?