Una funcion puede asumir ciertas cosas sobre lo que va a recibir.

Existe lo que se conoce como defensive programming que es basicamente tener una capa que valide los parametros de entrada antes de pasarselo a las funciones que “hagan algo”. Un ejemplo de esto es el pattern MVC donde el view valida los datos de entrada, y seria poco optimo y hasta confuso el volver a hacer las validaciones en el modelo.

Si vos tenes las “barricadas” para validar los datos que entran de los usuarios, las funciones que los reciben y procesan son mas bobas: menos logica es igual a menos lineas de codigo y existe cierta correlacion con menos bugs. El resultado final es un software mucho mas mantenible.

Ahora, segun esto tenes dos tipos de codigo: El que valida los datos de entrada y el que hace algo con eso datos: ¡Ambos pueden ser testeados!

Los que validan datos pueden ser encapsulados en funciones a las que dentro de un test case probas con datos tanto validos como invalidos y ves su resultado. Las que hacen algo con esos datos tambien las podes encapsular y meter los datos y observar el resultado controlando que sea el esperado.

TDD es lejos la mejor metodologia/filosofia para poder confiar en tu codigo, aun cuando dejaste de mantenerlo.

Pero también hay que recalcar que a veces el input de una función X no es lo que debería, y es algo que solamente “podría” ser probado con seguridad en todo su integridad.

Igualmente este paso se podría obviar si por ejemplo se probara la otra parte (el output que va a recibir la función), separadamente.