por - tdd wikipedia

¿Existe un enfoque viable para utilizar el desarrollo guiado por pruebas en una aplicación COBOL? (3)

Esta respuesta puede no ser tan fácil como tú (y yo) habíamos esperado.

He escuchado sobre COBOLunit antes, pero tampoco creo que se esté manteniendo actualmente ( https://sites.google.com/site/cobolunit/download ).

Nuestro equipo desarrolla un producto de software empresarial para la gestión de concesionarios de Auto / Truck / Ag, la gran mayoría de los cuales está en AcuCOBOL.

Pudimos abrir una brecha en la posibilidad de utilizar junit (pruebas de unidad para java) para ejecutar y evaluar las pruebas de unidad COBOL.

Esto requirió un adaptador de prueba personalizado que puede servir como la tubería y el cableado para los datos entre las pruebas de unidad COBOL y el marco Junit. En la aplicación que se va a probar, entonces necesitaremos agregar / diseñar ganchos que evaluarán la entrada como datos del caso de prueba, realizaremos la prueba con la que se relacionan los datos e informarán los resultados al adaptador. Estamos al comienzo de este experimento y no hemos pasado de la fase "es posible" a "es valioso". El primer inconveniente previsible (que creo que existe en todos los tdd) es cómo construir arneses en el programa.

¿Alguien ha encontrado algún enfoque viable para implementar el desarrollo guiado por pruebas (y el desarrollo guiado por comportamiento) en / para aplicaciones COBOL?

Una solución ideal permitiría realizar pruebas tanto de unidad como de integración tanto de cobol transaccional (CICS) como de modo por lotes, sobre la combinación habitual de bases de datos DB2 y varios conjuntos de datos de ancho fijo.

He visto http://sites.google.com/site/cobolunit/ , y parece interesante. ¿Alguien ha visto esto trabajando enojado? ¿Funcionó? ¿Cuáles fueron las trampas?

Solo para que fluyan sus jugos creativos, algunos "requisitos" para un enfoque ideal:

Debe permitir una prueba de integración para ejercer un programa completo de cobol.
Debe permitir que las pruebas certifiquen sus resultados (es decir, hacer afirmaciones a la xUnit)
Debe soportar tanto el modo batch como el cobol CICS.
Debe permitir que una prueba unitaria ejerza párrafos individuales dentro de un programa cobol mediante la manipulación del almacenamiento de trabajo antes / después de invocar el código bajo prueba.
Debe proporcionar la capacidad de ejecutar automáticamente una serie de pruebas (conjunto) e informar sobre el resultado general.
Debería ser compatible con el uso de dispositivos de datos de prueba que se configuran antes de una prueba y luego se desarman.
Debe separar limpiamente la prueba del código de producción.
Debería ofrecer una relación de código de prueba a producción típica de alrededor de 1: 1 (es decir, las pruebas de escritura no deberían multiplicar la cantidad de código escrito tanto que el costo general de mantenimiento aumenta en lugar de disminuir)
No debe exigir a los desarrolladores de COBOL que aprendan otro lenguaje de programación, a menos que esto entre en conflicto directamente con el requisito anterior.
Podría soportar informes de cobertura de código.
Podría fomentar la adopción de diferentes patrones de diseño dentro del propio código para hacer que el código sea más fácil de probar.

Comentarios bienvenidos sobre la validez / adecuación de los requisitos anteriores.

Solo un recordatorio de que lo que busco aquí es un buen consejo práctico sobre la mejor manera de lograr este tipo de cosas: no estoy necesariamente esperando una solución preempaquetada. Me encantaría con un ejemplo de cómo alguien ha usado TDD con éxito en cobol, junto con algunas pautas y errores sobre qué funciona y qué no.

Independientemente de cómo construya / ejecute las pruebas unitarias, es probable que necesite un resumen de qué tan bien se están realizando las pruebas y qué tan bien probado está el software resultante.

Vea nuestra herramienta de Cobertura de prueba SD COBOL , diseñada específicamente para IBM COBOL.

Tal vez echa un vistazo a QA Hiperstation . Sin embargo, podría costar mucho (al igual que cualquier otro producto de mainframe).

Solo lo usé brevemente hace mucho tiempo, así que no puedo pretender ser un experto. Lo usé para ejecutar y verificar una batería de pruebas de regresión en un entorno de tipo COBOL / CICS / DB2 / MQ-SERIES y me pareció bastante eficaz y flexible.

Yo diría que esta podría ser una de las piezas de tu rompecabezas, pero ciertamente no es todo.