La pregunta corta: ¿cómo se sigue el desarrollo impulsado por pruebas en un proyecto que abarca varios idiomas?
Específicamente, estoy escribiendo una aplicación web que usa JavaScript y PHP, y quiero seguir los principios de TDD, pero no estoy seguro de cómo integrarlos. ¿Ejecuto conjuntos de pruebas separados para las secciones JS y PHP, y uso simulacros en el conjunto JS para emular las respuestas del servidor? ¿Existe una técnica para la prueba unitaria de ambos componentes en una sola ejecución?
Esta es mi primera experiencia usando Test-Driven Development, por lo que cualquier consejo que pueda compartir sobre cómo hacerlo menos desalentador sería genial. La razón por la que lo elegí es que tan pronto como terminé un prototipo, los requisitos cambiaron, lo que me obligó a cambiar mi diseño. Pensé que si comenzaba de nuevo, me gustaría escribir un código más extensible con pruebas de regresión integradas desde el principio.
Estoy escribiendo mis pruebas de PHP en SimpleTest y mis pruebas de JavaScript en JsTestDriver. Estoy acostumbrado a los paradigmas orientados a objetos, así que tengo algunas clases en PHP, y estoy haciendo algo similar en JavaScript usando la herencia prototípica. También comencé a leer este libro sobre TDD en Python y este sobre TDD en JavaScript , pero por todo lo que he visto, estos no describen la prueba completa de una aplicación (aparte de usar algo como Selenium u otro controlador web para realizar pruebas de aceptación de front-end. ¿TDD simplemente no está hecho para desarrolladores full-stack?
fuente
Respuestas:
En realidad, eso sería lo opuesto a las pruebas unitarias: las pruebas unitarias, especialmente en el estilo TDD, significan probar sus componentes de forma aislada . Por lo tanto, la respuesta es sí, "ejecutar conjuntos de pruebas separados para las secciones JS y PHP ", de lo contrario no se trata de pruebas unitarias y no de TDD.
Por supuesto, las pruebas de integración automatizadas pueden probar "ambos componentes en una sola ejecución", y puede utilizar exactamente las herramientas que ya mencionó (como Selenium). Pero esas son típicamente pruebas más complejas, desarrolladas fuera de los ciclos TDD.
fuente
Lo importante es distinguir entre TDD y ATDD . El AT allí significa " pruebas de aceptación ", y esto se refiere al desarrollo en el que primero comienza con una prueba de aceptación, que es probable que pruebe toda la pila. Esto a veces también se llama "desarrollo impulsado por pruebas de afuera hacia adentro". Cuando la gente habla de TDD, la "T" allí probablemente se refiere específicamente a pruebas unitarias .
Una parte clave de las pruebas unitarias es aislar la unidad bajo prueba de sus dependencias. Esto le brinda dos beneficios muy importantes:
Puede hacer sus pruebas extremadamente rápido, por lo que puede ejecutarlas muy a menudo como parte de un ciclo de retroalimentación muy corto. En lugar de ejecutarlos, por ejemplo, cada hora, debería poder ejecutar todas las pruebas de su unidad después de cada pequeño cambio, de modo que obtenga instantáneamente sus comentarios sobre si ese cambio rompió algo.
Sus pruebas pueden dirigirse a un comportamiento muy específico a la vez. Si uno de ellos falla, debería poder determinar casi instantáneamente la naturaleza exacta del error que indica la prueba.
Debido a la importancia de este aislamiento, deseará automáticamente que las pruebas se restrinjan a unidades mucho más pequeñas de las que lo obligan sus límites de idioma. Aunque no es una regla difícil y rápida, a menudo esperarías que una sola clase sea una unidad comprobable. Entonces, en términos de TDD, el problema del idioma es más o menos irrelevante.
Si, por otro lado, quieres hacer ATDD, asegúrate de buscar recursos para esto específicamente (a menudo se hace como parte de BDD, así que mira las herramientas dirigidas a eso también). Aquí es donde encajaría naturalmente algo como Selenium. Por lo general, cuando se hace ATDD todavía se escriben pruebas unitarias, y de hecho, para aprobar cada prueba de aceptación, también se puede probar su implementación con pruebas unitarias. Entonces, incluso si desea hacer ATDD, comprender cómo escribir pruebas unitarias sigue siendo importante.
fuente
Además, no tiene que usar TDD para la pila completa de la aplicación. TDD como metodología de desarrollo es más adecuado para las partes lógicas de una aplicación. Las partes que requieren un toque más experimental, como el diseño de la interfaz de usuario, ciertas interacciones o el dominio de la base de datos, se realizan mejor en un estilo tradicional, ya que aún no se sabe si esa será la versión final.
Pero la lógica de la aplicación no debería cambiar en el futuro, y si lo hace, se enfrentará al temido requerimiento. Eso lo hace perfecto para un conjunto de pruebas de regresión para dar confianza cada vez que se realiza un cambio en el código, que es el objetivo final de TDD.
El tío Bob lo explica mejor que yo. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html
fuente