¿Es efectivo el código de procedimiento de prueba de la unidad?

12

En un proyecto actual, las potencias que se desean tener son las pruebas unitarias incorporadas en nuestro ciclo de desarrollo para evitar la cantidad constante de errores que parecen infiltrarse en nuestro código. El problema es que el código de espagueti tiene un 95% de procedimiento, con el que nunca he hecho pruebas de unidad (toda mi experiencia con pruebas de unidad ha sido con código OOP)

Entonces, mi pregunta en pocas palabras es si sería prudente continuar con las pruebas unitarias con nuestro código base actual, o sugerir que se posponga hasta que la aplicación haya sido migrada a un marco de trabajo adecuado.

PD: Aunque intenté diseñar esta pregunta como lenguaje independiente, creo que indicar que la aplicación en cuestión usa PHP y javascript ayudará a proporcionar respuestas más específicas que podrían responder a esta pregunta, ya que por experiencia, esto ocurre con la mayoría de estas aplicaciones.

    
pregunta canadiancreed 22.05.2012 - 05:50

5 respuestas

12

La prueba de la unidad funciona bien con los objetos, especialmente porque proporciona muchas características sofisticadas, como objetos simulados, que ayudan a crear mejores pruebas más rápido.

Dicho esto, nada prohíbe realizar pruebas de unidad en un código de base de procedimiento . En OOP, la mayoría de las pruebas unitarias son métodos de prueba pasándoles algunos parámetros y esperando un resultado o una excepción de un tipo específico. Esto también se puede hacer con el código de procedimiento; solo que en lugar de probar métodos, probará funciones .

Ten en cuenta que tendrás que:

  • Aísle las funciones que tiene que probar y las que no necesita. En OOP, esto es fácil: los métodos privados no tienen que probarse porque las personas que llaman nunca podrán acceder a ellos directamente. Es probable que, en su código de procedimiento, algunas funciones sean como esta y no necesiten pruebas.

  • Piense en ámbito global . El problema también existe en la POO, pero si dice que tiene que probar el código de espagueti, es probable que las personas que escribieron este código tengan malos hábitos, como usar el alcance global demasiado, y hacer algunas cosas locas como cambiar $_GET o $_POST arrays dentro de las funciones.

  • Tratar con código fuera de las funciones. Este es un caso más complicado, pero aún así es posible. O require_once una página para ver qué sucede y captura la salida a través de ob_start / ob_get_clean , o realiza una solicitud HTTP desde la serie de pruebas y analiza La respuesta analizando el HTML. Esto no es realmente una prueba de UI: aquí, no le importa si un botón en una página aparece a la izquierda o a la derecha o si un enlace está en mayúsculas rojas grandes o en letras azules pequeñas. Lo que te importa es encontrar algunos elementos HTML a través de DOM y comparar su contenido con el esperado.

  • Pruebe los códigos de respuesta . require_once con el búfer de salida es bueno, pero también tiene que probar cómo la aplicación web se ocupa de los errores. Por ejemplo, si el resultado esperado de una prueba es 404 No encontrado, debe hacer una solicitud HTTP para saber cuál es la respuesta.

respondido por el Arseni Mourzenko 22.05.2012 - 06:09
5
  

sugiere que se posponga hasta que la aplicación se haya migrado a un marco de POO adecuado

Realice algunas pruebas automáticas en su lugar antes de migrar a otra plataforma, no después. Agregue más pruebas mientras realiza la migración, no después. Si esas pruebas son "pruebas de integración" o pruebas unitarias, debe decidirlo usted mismo, pero normalmente puede usar su marco de prueba xUnit favorito para ambos tipos.

    
respondido por el Doc Brown 22.05.2012 - 08:38
4

Cada vez que tenga una situación en la que pueda probar partes de su código automáticamente, las pruebas unitarias pueden ser efectivas. Por lo tanto, la pregunta no es si el código de procedimiento se puede probar de manera efectiva, la pregunta es si ESTE código se puede probar de forma unitaria. Eso dependerá de cuánto estado lea y cuánto establezca. Lo ideal es que la respuesta a ambas sea cero, pero si no lo es, todavía puedes probarlo.

Como siempre, debe sopesar la confianza de que el código es correcto contra el costo de obtener esa confianza. Tenga en cuenta que parte de la ganancia para la prueba unitaria es identificar explícitamente las dependencias y, en ese sentido, es aún más efectivo para la prueba unitaria del código de procedimiento en comparación con el código OOP.

    
respondido por el jmoreno 22.05.2012 - 10:42
4

La forma más efectiva de iniciar las pruebas unitarias es identificar la clase de errores que ocurren con mayor frecuencia o son el costo más alto. A continuación, cree pruebas dirigidas a esos errores.

La forma en que se implementen esas pruebas diferirá entre paradigmas e idiomas. Las cosas más importantes que afectarán su capacidad para realizar pruebas unitarias son la calidad del código; menos así el paradigma utilizado. Recuerde que la prueba de unidad consiste en probar una "unidad" de código de forma aislada. Cualquier cosa que afecte su capacidad para aislar "unidades" de código hará que las pruebas sean más difíciles.

  • uso de globales
  • efectos secundarios
  • código estrechamente acoplado
  • código mal acoplado
  • un gran número de condicionales
  • "unidades" mal diseñadas

Todo esto tendrá un mayor impacto en la dificultad de las pruebas que el paradigma del idioma.

    
respondido por el dietbuddha 22.05.2012 - 08:51
-4

No creo que sea posible realizar pruebas de unidad verdaderas contra el código de procedimiento. El problema principal es que cada procedimiento probablemente tendrá muchas dependencias que no pueden eliminarse. En el mejor de los casos, las pruebas serán pruebas de integración. He hecho algo similar hace muchas lunas con los módulos VB6 y VBA en MS Access.

Dicho esto, si puedes poner andamios de prueba alrededor de los métodos que causan el mayor dolor, eso tiene que ser valioso, ¿no?

    
respondido por el Rob Gray 22.05.2012 - 05:59

Lea otras preguntas en las etiquetas