Estoy intentando adquirir el hábito de escribir pruebas unitarias regularmente con mi código, pero he leído que primero es importante escribir código verificable . Esta pregunta toca los principios SÓLIDOS de la escritura de código verificable, pero quiero saber si esos principios de diseño son beneficiosos (o al menos no perjudiciales) sin planear en absoluto escribir pruebas. Para aclarar - entiendo la importancia de escribir pruebas; Esto no es una pregunta sobre su utilidad.
Para ilustrar mi confusión, en la pieza que inspiró esta pregunta, el escritor da un ejemplo de una función que verifica la hora actual y devuelve algún valor dependiendo de la hora. El autor señala este código como incorrecto porque produce los datos (el tiempo) que usa internamente, lo que dificulta la prueba. Para mí, sin embargo, parece una exageración pasar en el tiempo como un argumento. En algún punto, el valor debe inicializarse, y ¿por qué no estar más cerca del consumo? Además, el propósito del método en mi mente es devolver algún valor basado en la hora actual , al convertirlo en un parámetro que implica que este propósito puede / debe cambiarse. Esto, y otras preguntas, me llevan a preguntarme si el código comprobable era sinónimo de código "mejor".
¿Sigue siendo una buena práctica escribir código comprobable aún en ausencia de pruebas?
¿Es el código comprobable realmente más estable? se ha sugerido como un duplicado. Sin embargo, esa pregunta es sobre la "estabilidad" del código, pero me pregunto de manera más general si el código también es superior por otras razones, como la legibilidad, el rendimiento, el acoplamiento, etc.