¿Es efectivo el código de procedimiento de prueba unitaria?

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

Entonces, mi pregunta en pocas palabras es ¿sería prudente proceder con las pruebas unitarias con nuestra base de código actual, o sugerir que se posponga hasta que la aplicación se haya migrado a un marco OOP adecuado?

PD: Si bien traté de diseñar esta pregunta como independiente del lenguaje, creo que afirmar 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 más con tales aplicaciones.

Las pruebas unitarias funcionan bien con los objetos, especialmente porque proporcionan muchas características sofisticadas, como objetos simulados, lo que ayuda a crear mejores pruebas más rápido.

Dicho esto, nada prohíbe hacer pruebas unitarias en una base de código de procedimiento . En OOP, la mayoría de las pruebas unitarias son métodos de prueba al pasarles algunos parámetros y esperar 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ás funciones .

Tenga en cuenta que tendrá 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 ser probados porque las personas que llaman nunca podrán acceder a ellos directamente. Lo más probable es que, en su código de procedimiento, algunas funciones sean así y no necesiten pruebas.

• Piensa en el alcance global . El problema también existe en OOP, pero si dices que tienes que probar el código de espagueti, lo más probable es que las personas que escribieron este código tengan malos hábitos, como usar demasiado el alcance global y hacer algunas cosas locas como cambiar $_GETo hacer $_POSTarreglos dentro funciones

• Tratar con el código fuera de las funciones. Este es un caso más complicado, pero aún posible. Puede require_onceir a una página para ver qué sucede y captar la salida a través de ob_start/ob_get_clean , o puede hacer una solicitud HTTP desde el conjunto de pruebas y analizar la respuesta analizando el HTML. Esto no es realmente una prueba de interfaz de usuario: 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 minúsculas azules. Lo que le interesa es encontrar algunos elementos HTML a través de DOM y comparar su contenido con el esperado.

• Prueba los códigos de respuesta . require_oncecon el búfer de salida es bueno, pero también debe probar cómo la aplicación web maneja 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.

sugiera que se posponga hasta que la aplicación se haya migrado a un marco OOP adecuado

Obtenga 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 decidir usted mismo, pero generalmente puede usar su marco de prueba xUnit favorito para ambos tipos.

La forma más efectiva de comenzar las pruebas unitarias es identificar la clase de errores que ocurren con mayor frecuencia o que son los de mayor costo. Luego cree pruebas que apunten a esos errores.

La forma en que se implementan esas pruebas diferirá entre paradigmas e idiomas. Lo más importante que afectará su capacidad para realizar pruebas unitarias es la calidad del código; menos así el paradigma usado. Recuerde que la prueba de unidad se trata de probar una "unidad" de código de forma aislada. Cualquier cosa que afecte su capacidad de aislar "unidades" de código hará que las pruebas sean más difíciles.

• uso de globals
• efectos secundarios
• código bien acoplado
• código mal acoplado
• una gran cantidad de condicionales
• "unidades" mal diseñadas

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

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. Entonces, la pregunta no es si el código de procedimiento puede ser probado de manera efectiva, la pregunta es si ESTE código puede ser probado de forma unitaria. Eso dependerá de cuánto estado lea y cuánto estado establezca. Idealmente, la respuesta a ambas es cero, pero si no lo es, aún puede 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 las pruebas unitarias es identificar explícitamente las dependencias, y en ese sentido es aún más efectivo probar el código de procedimiento de la prueba en comparación con el código OOP.

No creo que sea posible hacer pruebas unitarias verdaderas contra el código de procedimiento. El principal problema es que cada procedimiento probablemente tendrá muchas dependencias que no se pueden eliminar. 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 los módulos VBA en MS Access.

Dicho esto, si puede poner a prueba el andamiaje alrededor de los métodos que causan más dolor, eso tiene que ser valioso, ¿verdad?