¿Cuáles son las (des) ventajas de escribir pruebas unitarias en un idioma diferente al código?

Question

Las pruebas unitarias tienen requisitos diferentes que el código de producción. Por ejemplo, las pruebas unitarias pueden no ser tan efectivas como el código de producción.

Quizás a veces tenga sentido escribir las pruebas de su unidad en un lenguaje que se adapta mejor a las pruebas de unidad de escritura? El ejemplo específico que tengo en mente es escribir una aplicación en C# pero usando IronRuby o IronPython para escribir las pruebas.

mi punto de vista, el uso de IronPython y IronRuby tienen varias ventajas sobre el código C# como lenguaje de pruebas:

• que imita puede ser más simple en idiomas tipos dinámicos
• IronPython tiene anotaciones de tipo menos detallado que no son necesaria en la unidad de pruebas
• invocación Experimental de pruebas sin recompilación tecleando comandos en el intérprete

¿Cuáles son las ventajas y desventajas de utilizar dos idiomas diferentes para las pruebas y el código de producción?

Answer 1

desventajas que vienen a la mente:

• Dependiendo del idioma, que necesitan otro ambiente desarrollo (dependencia adicional del proyecto, un esfuerzo adicional para configurar una máquina de desarrollo, licencias adicionales, formación adicional. ..)
• La refabricación a veces es compatible con IDE, pero probablemente no sea para este otro idioma. Entonces, tiene que refactorizarlos manualmente.
• Las pruebas unitarias también se pueden utilizar como ejemplos de programación . Las pruebas muestran cómo las clases probadas están destinadas a ser utilizadas. Esto no funciona tan bien si las pruebas están escritas en un idioma diferente.

Answer 2

La mayor desventaja sería si alguien estuviera considerando el uso de pruebas unitarias para descubrir cómo se puede realizar una determinada acción, escribirla en otro idioma dificultaría su uso. También tendrías que cumplir con tu código C# CLS.

Answer 3

Principal desventaja, ya que veo que es mantenibilidad. Si codifica en C#, su equipo de desarrollo es competente en ese idioma, al igual que los nuevos empleados. Necesitas un equipo de desarrollo multifuncional.

Creo que también vale la pena señalar que probablemente no desee que las personas escriban sus pruebas en un idioma que quizás no sea el más fuerte. Su código de prueba debe ser robusto.

También debe cambiar entre sintaxis al escribir códigos/pruebas: esto es un poco molesto.

Answer 4

Un problema potencial obvio es una experiencia de depuración confusa. Personalmente, no he intentado depurar en todos los idiomas en .NET. ¿Qué sucede si ingresas al código C# de IronPython?

El otro problema es que cualquiera que desee desarrollar en su base de código debe conocer ambos idiomas.

Answer 5

Al construir una API o biblioteca, a menudo entrego pruebas de unidades como una forma de documentación sobre la mejor manera de utilizar la API o la biblioteca. La mayoría de las veces que construyo una biblioteca C#, la entrego a un cliente que escribirá código C# para usar la biblioteca.

Por razones de documentación, al menos algunas de mis pruebas siempre estarán escritas en el idioma de destino.

Answer 6

La mayor desventaja es que también está probando las dependencias del compilador en las pruebas de su unidad. En cierto sentido, esto también los convierte en pruebas de integración. Eso podría hacer que sean preferibles si espera que su código se pueda utilizar en varios idiomas, pero agrega un nivel de complejidad que puede no necesitar si su código solo se usa en producción con el lenguaje en el que está desarrollado.

Una ventaja que puedo ver es que aísla aún más el código que se está desarrollando a partir de la prueba en sí. Al separar el hecho de escribir la prueba aún más lejos del código actual en desarrollo, le obliga a realmente considerar cómo se debe escribir el código para pasar la prueba en lugar de simplemente mover el desarrollo inicial del código en la prueba en sí.

Answer 7

Soy un gran admirador de los lenguajes de hierro, pero hay desventajas significativas al usarlos para probar código compilado estáticamente. Probar Ruby/Python con Ruby/Python funciona muy bien, es decir, puedes falsificar objetos de muchas maneras. Pero probar C# con Ruby/Python puede llevar a más complejidad de la que se desea.

Considere un escenario en el que está escribiendo un proyecto ASP MVC en el que desea falsificar el tipo de navegador que realiza una solicitud al controlador. En C#, se podía burlarse fuera así (usando Moq):

var fakeRequest = new Moq.Mock<System.Web.HttpRequestBase>(); 
fakeRequest.Setup(request => request.Browser.Type).Returns("Fake"); 

en IronRuby, se vería algo como esto:

class FakeBrowser < HttpBrowserCapabilitiesBase 
    def type 
    "Fake" 
    end 
end 

class FakeRequest < HttpRequestBase 
    def browser 
    FakeBrowser.new 
    end 
end 

Cuanto más profundo es el contexto que debe ser falsificado a cabo, cuanto más complicado se vuelve. En C#, el marco de burla hace el subtipado automáticamente, pero en un lenguaje dinámico, lamentablemente, tendrá mucho trabajo por delante. Burlarse de bibliotecas como PyMock o Mocha no funcionará para pruebas como esta porque el código bajo prueba tiene fuertes dependencias de tipado y los objetos falsos generados por los frameworks de Ruby/Python no se ajustarán a esas dependencias. Me encantaría ver que la situación mejore a medida que IronRuby e IronPython maduren, pero ahora la prueba de la historia de C# no es tan buena.

Si mi opinión sobre esto es incorrecta, me encantaría que me corrijan. =)

Answer 8

Creo que esta es una excelente pregunta y una idea digna de consideración - en particular en un entorno como el Visual Studio/.NET, donde esto es fácilmente compatible

El lado positivo - como usted sugiere - es que puede optar por utilizar un lenguaje/herramienta para crear pruebas más adecuadas para la creación de pruebas que quizás el código que está utilizando para crear código, y por esta razón solo vale la pena pensarlo.

El inconveniente es que sus desarrolladores, los que crean las pruebas (y debemos recordar que no debemos confundir las pruebas unitarias con el diseño impulsado por pruebas) probablemente deberían tener fluidez en más de un idioma (sugeriría ¡que la capacidad de serlo es bastante importante para un buen desarrollador, pero soy parcial!) y, lo que es más importante, puede que tenga que preocuparse por las diferencias estructurales entre los dos (aunque, nuevamente, si habla de lenguajes .NET que debe estar cubierto para usted).

Se vuelve aún más interesante si va más allá de las pruebas de "unidad" a las pruebas en todos los niveles donde las capacidades específicas de idiomas particulares pueden dar ventajas en la construcción de un caso de prueba.

La pregunta final es si las ventajas superan las desventajas ... y eso es probablemente un caso específico.

Answer 9

Estoy de acuerdo con las otras respuestas de que hay desventajas, pero me sorprende que tan pocas hayan hablado sobre las ventajas.

• TDD'ing across languages ​​es una gran manera de aprender nuevos idiomas: escriba las pruebas en un idioma que conozca bien y la implementación en el idioma que está aprendiendo. A medida que vayas aprendiendo, descubrirás mejores formas de escribir el código que antes, pero refactorizar es fácil porque tienes un conjunto de pruebas.
• Tener que dominar varios idiomas lo mantiene a usted (y a su equipo) en forma.
• Obtienes una mejor verificación de que tu API es interoperable en todos los idiomas.

Answer 10

Experiencia 1

En el pasado año trabajé en un proyecto que tenía dos piezas principales:

1. A Griales aplicaciones web
2. y una aplicación Java Swing

escribimos nuestras pruebas de unidad Java usando Groovy y funcionó bien. Las pruebas unitarias con Groovy tomaron mucho menos tiempo en cuanto a la verbosidad y también permitieron simular métodos estáticos y demás. Aunque hubo un par de lugares donde encontramos resultados inesperados debido al tipado dinámico de Groovy, en general fue una experiencia positiva.

Experiencia 2

Otro proyecto reciente que trabajé fue una aplicación web C# ASP.NET MVC 3 donde escribí todas las pruebas unitarias con F #. Elegí C# para la aplicación web porque sentí que funcionaba mejor con MVC 3. Elegí F # para las pruebas unitarias porque es mi idioma favorito. Los únicos problemas con los que me encontré fueron molestias menores con tipos como null vs. option.

Conclusión

Cuando tenemos dos idiomas dirigidos al mismo tiempo de ejecución (bueno, C#/F # y Java/Groovy en CLR y JRE respectivamente), donde una se utiliza para el código de producción y una para pruebas de unidad, hay ISN' demasiado para preocuparse por la compatibilidad, al menos. Entonces creo que realmente se trata de si usted y su equipo se sienten lo suficientemente cómodos en ambos idiomas (y supongo que usted también tendrá la amabilidad de considerar a los futuros mantenedores). De hecho, creo que los tiempos en los que se vería obligado a utilizar un idioma diferente para las pruebas unitarias es cuando el idioma de prueba de la unidad es en realidad su lenguaje de comodidad o elección sobre su lenguaje de producción.

Hay algunas excepciones que admito a esta actitud liberal. Si está diseñando una biblioteca para ser consumida por el lenguaje X, puede ser una buena idea escribir las pruebas unitarias en el lenguaje X (algunas al menos). Pero para el código de la aplicación, nunca encontré particularmente ventajoso escribir pruebas unitarias en el mismo idioma que su código de producción.