Preguntas sobre pruebas unitarias y desarrollo guiado por pruebas

7

Estoy trabajando en un sitio web ASP.NET MVC que realiza cálculos relativamente complejos como una de sus funciones.

Esta funcionalidad se desarrolló hace algún tiempo (antes de comenzar a trabajar en el sitio web) y se han producido defectos por los cuales los cálculos no se están calculando correctamente (básicamente, estos cálculos se aplican a cada usuario que tiene ciertas marcas en su registro, etc.).

Nota; estos defectos solo han sido observados por los usuarios hasta el momento, y aún no se han investigado en el código durante la depuración.

Mis preguntas son:

  • Debido a que la unidad existente prueba todas las pasadas y, por lo tanto, no indica que los defectos que se han informado existen ¿Esto sugiere que el código original que se implementó es incorrecto? es decir, ¿los requisitos eran incorrectos y estaban codificados en consecuencia o simplemente no estaban codificados como se suponía que estaban codificados?

  • Si utilizo el enfoque TDD, descartaría las pruebas unitarias existentes ya que no muestran que haya problemas con la funcionalidad de los cálculos, y comienzo haciendo algunas pruebas unitarias fallidas que prueban / prueban que existen ¿Se producen estos problemas y luego agrega el código para hacerlos pasar?

Nota; si es simplemente un error que está ocurriendo y se puede encontrar al depurar el código, ¿es necesario actualizar las pruebas unitarias ya que ya están pasando?

    
pregunta Theomax 23.09.2012 - 11:25

4 respuestas

5

Respuesta corta: Lo más probable es que las pruebas unitarias no estén bien diseñadas para cubrir los escenarios de cálculo críticos. Además, puede haber modificaciones / cambios en las reglas de negocios que no están cubiertos en las pruebas de unidades existentes, debido a millones de razones que uno puede enfrentar en un entorno de desarrollo bien programado.

Como también se mencionó:

  

Las pruebas unitarias automáticas no implican que las pruebas finales cubran todos los casos y que el código sea absolutamente correcto y libre de errores. Es fácil no ver algunos casos de uso complejos y posibles errores.

Puede haber millones de razones por las que NO se hace correctamente . Lo que quiero decir es que debe cubrir estos casos con propietario del producto , y luego realizar cada prueba de unidad y verificar la implementación aplicando el nombre correcto de cada prueba de unidad, así como agregando los faltantes una vez.

  

Si utilizo el enfoque TDD, descartaría las pruebas unitarias existentes, ya que no muestran que haya algún problema con la funcionalidad de los cálculos, y comienzo haciendo algunas pruebas unitarias fallidas que prueban / prueban que ocurren estos problemas , y luego agregar código para hacerlos pasar?

TDD (desarrollo guiado por pruebas) seguramente será una ayuda, pero NO descartaría el conjunto actual de pruebas unitarias en la medida en que hagan lo que se supone que deben hacer.

    
respondido por el EL Yusubov 23.09.2012 - 20:54
9

El uso de TDD y las pruebas unitarias automáticas no implican que las pruebas finales cubran todos los casos y el código sea absolutamente correcto y libre de errores. Es fácil no ver algunos casos de uso complejos y posibles errores.

Por otra parte,

TDD facilita la introducción de cambios para aquellos casos que no se han pensado antes. Simplemente repita TDD como si estuviera desarrollando:

  1. Escriba un nuevo caso de prueba, que falla
  2. Implementar código, que hará que esta prueba tenga éxito
  3. Código de refactor para eliminar duplicidades e introducir buenas abstracciones mientras se pasan todas las pruebas
respondido por el Euphoric 23.09.2012 - 11:34
3

Esta es exactamente la razón por la que querría considerar el desarrollo impulsado por el comportamiento y el desarrollo impulsado por las pruebas de aceptación: las pruebas unitarias no son una garantía sobre si el sistema está haciendo lo que se supone que debe hacer: comprueba solo si hace lo que era diseñado para hacer. La otra cara es que los propietarios de productos / analistas de negocios no pueden revisar estas pruebas muy fácilmente para verificar que sean correctas.

Por otra parte, si utiliza pruebas de aceptación, los analistas de negocios u otras personas que no son de tecnología pueden verificarlas fácilmente. Eso puede ser bastante útil.

En su caso particular, yo diría que el propietario del producto debería tomar la decisión de si se trata de errores o no, si es así, obviamente las pruebas existentes son incorrectas o por lo menos insuficientes, y tendrá que escribir los nuevos (que fallan) y tal vez incluso eliminar algunos de los antiguos (que están esperando cosas incorrectas) antes de escribir el código que pasa las nuevas pruebas.

    
respondido por el Roopesh Shenoy 23.09.2012 - 14:51
1

No creo que las pruebas unitarias prueben necesariamente los requisitos: 1) las pruebas unitarias operan contra componentes de muy bajo nivel (métodos / clases / interfaces / etcétera) probados como unidades independientes; 2) se supone que los requisitos deben probarse mientras el ingeniero de pruebas diseña la integración / pruebas del sistema durante la fase de diseño de requisitos; 3) la funcionalidad, los requisitos y las especificaciones se prueban (nuevamente) una vez que el sistema se encuentra en un estado operativo; y 4) utilizando un enfoque de desarrollo de software iterativo, se revisan muchas fases del ciclo de vida del desarrollo para reforzar los requisitos, el diseño y el desarrollo, procesos que se repiten.

Por qué las pruebas unitarias no son adecuadas para los requisitos de prueba . La prueba de unidad no necesariamente descubrirá un problema de requisitos por varias razones. Uno, si un requisito se comunicó de manera deficiente, es probable que el requisito se haya incorporado al diseño del software y al desarrollo posterior; como resultado, si la prueba de la unidad sigue el ejemplo, siguiendo correctamente un requisito incorrecto, la prueba de la unidad no generará nada. Dos, si el requisito se documentó correctamente, y el equipo de desarrollo interpretó incorrectamente el requisito, similar al elemento 1, la interpretación errónea se llevará a cabo a la prueba de la unidad. Tres, según mi experiencia, las pruebas unitarias las realiza el desarrollador, y forman parte del ciclo de vida del desarrollo: las pruebas unitarias son de bajo nivel y probablemente no representen un requisito, a menos que cada requisito completo esté representado por su propio método. que es muy, muy poco probable.

Ejemplo . Considere la prueba de unidad en términos de métodos. La prueba de unidad verifica en gran medida que dadas las condiciones previas, las condiciones posteriores se mantienen después de la ejecución del método bajo prueba. El objeto de la prueba unitaria es probar / verificar los métodos, etcétera, de un sistema de software, a partir de los métodos más atómicos o primitivos, avanzando hacia los más complejos. Al probar cada método de bajo nivel, verificas si funciona, no lo crees. En esta etapa, el desarrollador no necesita volver a probar el método de bajo nivel nuevamente como una unidad independiente. Al avanzar en complejidad hacia métodos de nivel superior, las pruebas unitarias verifican estos métodos, lo que demuestra que los métodos primitivos, a partir de los cuales se componen los métodos de nivel superior, funcionan juntos. Por lo que sé, esto es prácticamente donde se detienen las pruebas unitarias.

Cómo se prueban los requisitos . En un proyecto bien planificado, el ingeniero de pruebas (un probador integrado / del sistema), comienza a diseñar pruebas mientras se escriben los requisitos. A través de esta actividad, los requisitos se verifican antes del diseño del sistema y mucho antes de que se escriba una puntada de código. Una vez que el sistema esté disponible en alguna forma utilizable, los requisitos se verifican mediante pruebas funcionales / de integración / del sistema.

    
respondido por el Matthew Helm 25.09.2012 - 20:05

Lea otras preguntas en las etiquetas