¿Hay algún marco de prueba de unidad agnóstico de lenguaje? [cerrado]

11

Siempre he sido escéptico de reescribir el código de trabajo; el código de transferencia no es una excepción a esto. Sin embargo, con la llegada de TDD y las pruebas automatizadas, es mucho más razonable reescribir y refactorizar el código.

¿Alguien sabe si hay una herramienta TDD que se pueda usar para portar código antiguo? Idealmente, podría hacer lo siguiente:

Escriba pruebas de unidad agnósticas de lenguaje para el código antiguo que pasa (¡o falla si encuentra errores!).
Ejecute pruebas unitarias en su otra base de código que fallan.
Escriba el código en su nuevo idioma que pase las pruebas sin mirar el código anterior.

La alternativa sería dividir el paso 1 en "Escribir pruebas unitarias en el idioma 1" y "Realizar pruebas unitarias de puertos en el idioma 2", lo que aumenta significativamente el esfuerzo requerido y es difícil de justificar si la antigua base de código dejará de mantenerse después de el puerto (es decir, no obtiene el beneficio de la integración continua en esta base de código).

EDITAR: Vale la pena señalar esta pregunta en StackOverflow.

unit-testing language-agnostic porting

— Bringer128
fuente

Proporcione un protocolo de comando de texto puro y luego úselo expectpara implementar sus pruebas.

— SK-logic

@ SK-logic no había oído hablar de él expect. Si tiene un sistema heredado de estilo Unix que se comunica con tuberías mediante stdin y stdout, entonces esa herramienta se puede usar con seguridad. De hecho, sería bastante fácil probar con cualquier lenguaje de script también.

— Bringer128

¿Por qué legado? También puede tener un sistema moderno de estilo unix. De todos modos, nunca existe una justificación válida para no proporcionar una interfaz de secuencias de comandos para ninguna pieza de funcionalidad.

— SK-logic

@ SK-logic Perdón por no ser claro. Dije "legado" porque la transferencia se realiza generalmente de legacy language xa fancy new language y. ¡No estaba tratando de implicar nada sobre Unix!

— Bringer128

@ Bringer123, por cierto, mi pequeño truco para hacer este tipo de integración tipo Unix sin ningún soporte decente para Unix (por ejemplo, sin canalizaciones adecuadas) es incrustar un lenguaje de script y proporcionar acceso a su REPL a través del puerto TCP (con REPL ejecutando en un hilo separado). Es una poderosa herramienta de depuración y un motor de automatización de pruebas. Y este enfoque funciona literalmente con todo (un lenguaje de script incorporado puede ser realmente pequeño, incluso puede ser un Forth en un escenario de recursos limitados).

— SK-logic

6

No creo que sea posible escribir pruebas unitarias en un idioma diferente.

Sin embargo, lo que puede hacer es escribir pruebas de integración / aceptación / interfaz de usuario / whaterver_you_name_it que serían de muy alto nivel y no estarían vinculadas al idioma con el que está escrito su software.

Si su aplicación es un servicio web, puede probarla con el idioma que desee, siempre que sea compatible con su protocolo. Si su aplicación se ejecuta en un navegador, puede usar selenio (eso fue lo primero que se me ocurrió, pero hay otros. Etc. Puede haber algunos casos en los que no funcionaría, imagino (tal vez cosas de hardware), todo depende sobre el tipo de aplicación en la que está trabajando.

Por supuesto, no tendrá la misma cobertura que tendría con las pruebas de nivel de unidad (a menos que pase mucho tiempo), pero al menos, tendría un arnés de prueba.

— David
fuente

+1 para las pruebas automatizadas de alto nivel. Definitivamente valdría la pena el esfuerzo de producir.

— Bringer128

1

"No creo que sea posible escribir pruebas unitarias en un idioma diferente". : ejemplo de contador: en .NET, puede escribir pruebas unitarias de C # en Visual Basic (o cualquier otro lenguaje habilitado para .NET). Hace unos años, Microsoft incluso promovió esto como una práctica recomendada, ya que reduce el riesgo de cometer tanto en el código como en las pruebas el mismo error relacionado con el lenguaje (y específicamente el malentendido relativo del programador). De acuerdo, no se escribirán pruebas unitarias en Fortran para probar el código PHP.

— Arseni Mourzenko

2

Creo que lo que más se acerca a su idea son los marcos de prueba de unidad en ecosistemas basados en máquinas virtuales, como la máquina virtual Java. Al menos Scala (y creo que Groovy también, no estoy muy seguro de Clojure) es casi perfectamente interoperable con Java. Es decir, el código Scala se puede probar con JUnit y el código Java se puede probar con ScalaTest. De esta manera, puede (gradualmente o de una vez) reescribir el código Java en Scala y seguir usando las mismas pruebas unitarias de Java para verificar su corrección. (O al revés, aunque no puedo imaginar una razón válida para migrar de Scala a Java).

Probablemente lo mismo es cierto para los lenguajes en la CLI de .NET, por ejemplo, C #, F #, ASP.NET et al.

Fuera de una VM / CLR, sin embargo, es más difícil. En teoría, uno podría compilar pruebas unitarias y / o código bajo prueba en otro lenguaje como C (como era y es común con nuevos lenguajes como C ++ temprano, etc.), pero no he oído hablar de nadie que pruebe esto específicamente con pruebas unitarias.

— Péter Török
fuente

1

Supongo que esto muestra el problema con mi pregunta. Si pueden interoperar fácilmente, ¿por qué babor? Y si no pueden, entonces la barrera del idioma hace que sea imposible hacer pruebas unitarias entre idiomas.

— Bringer128

@ Bringer128, los defensores de la nueva generación de lenguajes JVM afirman que los problemas específicos se pueden resolver más rápido, con un código significativamente menor y más limpio que en Java. Mi limitada experiencia con Scala lo confirma hasta ahora.

— Péter Török

Groovy también interactúa con Java.

— user281377

1

Dicho marco no existe, porque debe escribirse en el idioma del código que se utiliza.

Por ejemplo, un marco para probar el código de C ++ debe escribirse en C o C ++. El uso de framework escrito en c ++ podría, pero no va a probar el código ac si usa características de c ++.

— BЈовић
fuente

1

Las metodologías varían, pero en mi caso, una gran parte de mis pruebas TDD tienden al estilo de 'prueba de integración', a diferencia de la 'prueba unitaria'. Es decir, la mayoría de ellos prueban todo el programa en consultas de la vida real, buscando respuestas apropiadas.

En algunos casos, cuando escribí programas dirigidos por la red (en su mayoría protocolos específicos de la aplicación), no tenía un marco de prueba completo a mano que se sintiera fácil para el trabajo, así que hice la mayoría de las pruebas 'a través de la red', en En resumen, escribí un cliente muy simple en otro idioma con un marco de prueba común y simple, y la mayoría de las pruebas verificaron las respuestas del servidor.

Aún así, incluso en esos casos, inyecté algunas pruebas manuales en la aplicación real para probar algunas partes que no son de red.

— Javier
fuente

0

El marco de prueba agnóstico del lenguaje es un marco de prueba genérico adecuado para la prueba de aceptación (punto de vista) y los casos de prueba en ese marco son administrados por QA, por ejemplo, Robotframework

— rrsguru
fuente

2

Esto no parece ofrecer nada sustancial sobre los puntos hechos y explicados en las 4 respuestas anteriores

— mosquito