python - ¿Es una práctica aceptable probar un programa en un idioma diferente?
c++ unit-testing (5)
Diría que es mejor probar la API a la que estarán expuestos los usuarios. También es bueno tener otras pruebas, pero ese es el aspecto más importante.
Si sus usuarios van a escribir código C / C ++ que enlaza con su biblioteca, entonces sería bueno tener pruebas que usen su biblioteca de la misma manera.
Si va a enviar una envoltura de Python (¿por qué no?), Entonces debería hacerse pruebas de Python.
Por supuesto, hay un aspecto de conveniencia a esto, también. Puede ser más fácil escribir pruebas en Python, y es posible que tenga limitaciones de tiempo que lo hagan más atractivo, etc.
Supongo que lo que digo es que no hay nada intrínsecamente malo en que las pruebas estén en un idioma diferente del código bajo prueba (eso es totalmente normal para probar una API REST, por ejemplo), pero asegúrese de tener pruebas para el público. API como mínimo.
Aparte, en terminología:
No creo que los tipos de pruebas que está describiendo sean "pruebas unitarias" en el sentido habitual del término. Probablemente la "prueba funcional" sería más precisa.
Una prueba de unidad normalmente prueba un componente muy pequeño, como una llamada a una función, que podría ser una pieza de una funcionalidad más grande. Las pruebas unitarias como estas a menudo son pruebas de "caja blanca", por lo que puede ver el funcionamiento interno de su código.
Las pruebas desde el punto de vista de un usuario (como las pruebas de línea de comando de su profesor) son pruebas de "caja negra", y en estos ejemplos se encuentran en un nivel más funcional en lugar del nivel de "unidad".
Sin embargo, estoy seguro de que muchas personas no están de acuerdo con eso, no es un conjunto de términos rígidamente definido.
Tengo una biblioteca estática que creé desde C ++ y me gustaría probarla con un código de controlador.
Noté que a uno de mis profesores le gusta hacer sus pruebas usando python, pero simplemente ejecuta el programa (no una biblioteca en este caso, sino un ejecutable) usando argumentos de prueba aleatorios.
Me gustaría adoptar este enfoque, pero me di cuenta de que esta es una biblioteca y no tiene una función principal; eso significaría que debería crear una clase Driver.cpp o envolver la biblioteca en python utilizando SWIG o impulsar python.
Planeo hacer esto último porque parece más divertido, pero lógicamente, siento que habrá más errores al intentar ajustar una biblioteca a un idioma diferente solo para probarlo, en lugar de probarlo en su idioma nativo. .
¿Las pruebas de programas en un idioma diferente son una práctica aceptada en el mundo real, o es esta mala práctica?
Por qué no, es una idea increíble porque realmente entiendes que estás probando la unidad como una caja negra.
Por supuesto, puede haber problemas técnicos involucrados, y si necesita burlarse de algunas partes de la unidad bajo prueba, eso puede ser difícil en un idioma diferente.
Esta es una práctica común para las pruebas de integración, sin embargo, he visto muchos programas impulsados desde herramientas externas como un sitio web de selenio o una aplicación de pepino. Ambos pueden considerarse lo mismo que un script de Python personalizado.
Si considera que la diferencia entre las pruebas de integración y las pruebas unitarias es la cantidad de cosas que se están probando en un momento dado, la única razón por la que no debería hacer esto es por el soporte de herramientas.
Realmente depende de qué es lo que estás tratando de probar. Casi siempre tiene sentido escribir pruebas unitarias en el mismo idioma que el código que está probando para que pueda construir los objetos bajo prueba o invocar las funciones bajo prueba, ambas de las cuales se pueden hacer más fácilmente en el mismo idioma y verificar Que funcionen correctamente. Sin embargo, hay casos en los que tiene sentido utilizar un lenguaje diferente, a saber:
Pruebas de integración que ejecutan una serie de diferentes componentes o aplicaciones juntas.
Pruebas que verifican fallas de compilación o interpretación que no se pudieron probar en el idioma en sí, ya que está validando que se produce un error en el nivel de idioma.
Un ejemplo de # 1 podría ser un programa que inicia múltiples servidores diferentes conectados entre sí, emite solicitudes al servidor y verifica esas respuestas. O, como un ejemplo más simple, un programa que simplemente ejecuta una solicitud de prueba como un subproceso y verifica que produce los resultados esperados para una entrada determinada.
Un ejemplo de # 2 podría ser un programa que verifique que una determinada pieza de código C ++ producirá una falla de afirmación estática o que una creación de instancias de una plantilla particular que se desactiva intencionalmente resultará en una falla de compilación si alguien intenta usarla.
Para responder una pregunta más amplia, no es una mala práctica per se escribir exámenes en otro idioma. Todo lo que hace que las pruebas sean más convenientes para escribir, más fáciles de entender, más sólidas para los cambios en la implementación, más sensibles a las regresiones y mejor en cualquiera de las propiedades que definen una buena prueba sería una buena justificación para escribir las pruebas de una manera frente a otra . Si eso significa escribir las pruebas en otro idioma, entonces hágalo. Dicho esto, las pruebas de unidades pequeñas normalmente necesitan poder invocar el elemento bajo prueba directamente, lo que en la mayoría de los casos significa escribir las pruebas de unidad en el mismo idioma que el componente bajo prueba.
Un par de cosas a tener en cuenta:
Si está escribiendo pruebas a medida que codifica, entonces, por todos los medios, use el idioma que mejor funcione para darle una respuesta rápida. Esto permite ciclos rápidos de código de prueba (y también es divertido). PERO
Siempre tenga pruebas bien escritas en el idioma del consumidor . ¿Cómo van a llamar tus funciones tu cliente / consumidor? ¿Qué idioma van a utilizar? El uso del mismo lenguaje minimiza los problemas de integración más adelante en el ciclo de vida.
Diría que depende de lo que realmente intentes probar. Para las pruebas de unidad verdaderas, creo que es mejor probar en el mismo idioma, o al menos en un lenguaje compatible con binarios (es decir, probar Java con Groovy ; uso Spock en este caso, que está basado en Groovy , a la unidad). pruebe mi código Java , ya que puedo mezclar Java con Groovy ), pero si está probando los resultados , creo que es justo cambiar de idioma.
Por ejemplo, he probado los resultados esperados cuando me dieron un conjunto específico de datos al ejecutar una aplicación de Perl través de la nose en Python . Esto funciona porque no estoy probando el código Perl, per se, sino los resultados de ese código Perl.
En ese caso, para probar las funciones de Perl reales que forman parte de la aplicación, usaría un marco de prueba basado en Perl como Test::More .