Las excepciones de argumento deben probarse por unidad?

Question

Sé que esta pregunta es muy similar a otras que se han publicado anteriormente, pero me gustaría discutir este tema de manera adecuada.

¿Cree que la excepción "obvia" debe probarse en una unidad?

Con la excepción obvia me refiero, por ejemplo, a excepciones por argumentos nulos o cadenas vacías o números negativos en situaciones donde la lógica comercial de nuestra unidad nos hace obvio que estas excepciones siempre serán arrojadas al principio de nuestro método.) antes de cualquier otra operación.

En otras palabras, estoy hablando de las excepciones que se deben lanzar después de la violación de la parte más simple de un contrato de clase.

Gracias por su opinión.

Answer 1

Normalmente incluyo estas pruebas. Es realmente un buen lugar para comenzar el desarrollo, porque si usas TDD puedes tener la prueba más simple posible para comenzar a escribir código de producción, y si no usas TDD tienes una buena prueba de aprobación :)

Answer 2

Absolutamente. Usted los llama "obvios", pero no hay nada obvio en recordar verificar las condiciones previas. De hecho, la mayor parte del código que he visto en mi carrera no toma este paso obvio para evitar el caos más adelante.

Si bien esto se ve mucho en el código de la biblioteca que está escrito para consumo público, reutilización, etc., la mayoría de los desarrolladores parecen pasar por alto tales comprobaciones. En un entorno basado en pruebas, poner pruebas para tales condiciones obliga a los desarrolladores a validar correctamente los parámetros de entrada en sus métodos públicos.

Y seamos justos ... tengo la oportunidad de escribir otra prueba y ver la barra verde, estoy contento. :)

Answer 3

Sí, debe probar la unidad, incluso la lógica más simple en sus getters y setters. Si ese código cambia durante la refactorización, quiere que la red de seguridad de la prueba de la unidad esté en su lugar para asegurarse de que no se cometan errores. Ejecutar las pruebas es una manera muy rápida de encontrar estos errores tan pronto como se realicen.

La única vez que no pruebo getters y setters es si están haciendo solo asignación simple o devolviendo un valor.

Answer 4

yo siempre escribo también una prueba para este tipo de cosas "simples, obvios" sobre todo porque

• Un ensayo de acuerdo para estas situaciones "obvios" se escribe generalmente muy rápidamente y por lo tanto soy más rápido en casi escribir rápidamente que en lugar de pensar en el hecho de si poner o no una prueba
• un caso de prueba simple es mejor que ningún caso de prueba
• de prueba para futuros cambios. Tener una prueba asegura que cualquier otro desarrollador de mi equipo no rompa mi código durante la refactorización/corrección de errores, etc. ...