Soy un defensor vocal de la metodología de Desarrollo Conducido por el Comportamiento (también conocido como BDD). He estado aplicando BDD durante un par de años y he adoptado StoryQ como mi marco de elección al desarrollar aplicaciones DotNet. A pesar de que he estado haciendo pruebas unitarias durante muchos años, y previamente había cambiado a un enfoque de prueba primero, descubrí que obtengo mucho más valor al usar un marco BDD, porque mis pruebas capturan la intención de los requisitos en relativamente inglés claro dentro de mi código, y debido a que mis pruebas pueden ejecutar múltiples aserciones sin terminar la prueba a la mitad, lo que significa que puedo ver qué aserciones específicas pasan / fallan de un vistazo sin depurar para probarlo.
Esto realmente ha sido la punta del iceberg para mí, ya que también he notado que puedo depurar tanto el código de prueba como el de implementación de una manera más específica, con el resultado de que mi productividad ha crecido significativamente y que puedo más determine fácilmente dónde ocurre una falla si ocurre un problema para llegar a la compilación de integración debido a la salida que llega a los registros de compilación. Además, la API StoryQ tiene una sintaxis fluida encantadora que es fácil de aprender y que se puede aplicar de muchas maneras, sin necesidad de dependencias externas para usarla.
Entonces, con todos estos beneficios, pensaría que es fácil presentar el concepto al resto del equipo. Desafortunadamente, los otros miembros del equipo son reacios incluso a mirar StoryQ para evaluarlo adecuadamente (y mucho menos considerar la idea de aplicar BDD), y se han convencido mutuamente para tratar de eliminar una serie de elementos de StoryQ de nuestro propio marco de prueba central, incluso aunque originalmente admitieron el uso de StoryQ, y aunque el código que desean eliminar no afecta a ninguna otra parte de nuestro sistema de prueba. Si lo hace, terminaría aumentando mi carga de trabajo significativamente en general y realmente va en contra de la corriente, ya que estoy convencido por experiencia práctica de que es una mejor manera de trabajar en un entorno de trabajo particular y solo puede conducir a una mayor mejoras en la calidad de nuestro software, dado que ' Me ha resultado más fácil seguir con la prueba usando BDD. Para aclarar aún más, la mayoría de las pruebas unitarias que tenemos tienden a ser bastante frágiles y difíciles de mantener, un remanente de años de pruebas mal aplicadas donde la renuencia a seguir un proceso basado en pruebas ha visto a los desarrolladores recurrir a viejos hábitos y haga todas sus pruebas al final del proyecto (¡estas mismas personas dicen ser ágiles!).
Entonces la pregunta realmente se reduce a lo siguiente:
- ¿Qué argumentos puedo usar para realmente señalar que sería mejor para este equipo usar StoryQ, o al menos adoptar la metodología BDD?
- ¿Puede señalarme alguna evidencia anecdótica que pueda utilizar para apoyar mi argumento de adoptar BDD como nuestro método estándar de elección?
- ¿Qué contraargumentos puedes pensar que sugieran que mi deseo de alentar al equipo a adoptar BDD podría ser un error? Sí, estoy feliz de que se demuestre que estoy equivocado, siempre que el argumento sea sólido.
NOTA : No estoy abogando por que reescribamos nuestras pruebas en su totalidad, sino que simplemente comencemos a trabajar de una manera diferente para todo el trabajo de prueba futuro, y preferiblemente en la forma en que involucramos a nuestros clientes.
Y para aquellos de ustedes que deseen aprender más sobre BDD, los siguientes enlaces pueden ser útiles:
- http://dannorth.net/introducing-bdd/
- http://en.wikipedia.org/wiki/Behaviour_driven_development
- http://behaviour-driven.org/Introduction
Para aquellos interesados en más detalles, somos un pequeño equipo de 4 personas que trabajan en aproximadamente 5 proyectos grandes. La "prueba piloto" para BDD se ejecutó durante aproximadamente 2 meses inicialmente, con otro período de aproximadamente 4 meses después. El equipo aceptó que debía continuar trabajando de esta manera y que debía hacer sus propias pruebas. He estado BDD durante aproximadamente 2 años desde que terminó el juicio, mientras que los otros se han vuelto muy buenos para esquivar el problema. En lugar de forzar una "confrontación" sobre el tema, estoy buscando maneras de persuadir suavemente al equipo para que se salga de sus espaldas colectivas y se tome el tiempo para hacer su parte.