Me encantaría impulsar el desarrollo de TDD dentro de la tienda en la que estoy trabajando. Muchas de las personas mayores no trabajaron con las pruebas unitarias o las pruebas unitarias que estaban llegando a la base de datos.¿Cómo convertir una tienda de software a TDD?
Me encantaría traer algunos buenos argumentos, libros para entrenar, posibles entrenadores para facilitar la transición.
He descubierto que a menudo es muy difícil empujar TDD desde el desarrollador. Lo que tiendo a hacer es hablar de los beneficios de TDD tanto como sea posible y, siempre que sea posible, introducir elementos de TDD yo mismo poco a poco.
Si no les importa, inicie un nuevo proyecto con pruebas unitarias en él (los gerentes rara vez se preocupan por más pruebas) y comience a desarrollarlo usted mismo. Lentamente demuestre al resto de su equipo los beneficios y trate de ganar algunos conversos. Una vez que tenga algunos otros desarrolladores de su parte, comience a presionar a la gerencia para que reciba capacitación.
También podría ofrecer ejecutar algunos lunch-n-learns al respecto para los otros desarrolladores. La enseñanza es la mejor manera de aprender y esperamos tener aliados. Si tiene suerte, puede pedirle a su jefe que compre la pizza para el almuerzo-n-learn y que todos se beneficien.
Si el proyecto no tiene suficientes pruebas de unidad, puede señalar errores en la base de datos de problemas que probablemente se habrían evitado si se hubieran realizado pruebas unitarias.
En cuanto a presionar TDD, o algún otro código de religión, no se moleste.
Para algunas personas (y algunos tipos de código), TDD es excelente. Algunas personas no trabajan de esa manera, y no se benefician de la prueba primero. Siempre y cuando no eviten las pruebas por completo, no creo que importe.
Me gusta Rob P dijo - También encontré que la predicación me terminó con una voz ronca y nadie escuchando. Obtuve resultados más rápidos y generalizados haciéndolo y manteniendo esa parte visible. Esté abierto a preguntas y no lo fuerce. Anime y alabe pero no predique.
Combínelo con la publicación de los resultados de sus pruebas, y tenga eso automatizado, puede enviar un correo electrónico, tal vez. Desea muchos recordatorios sutiles para mostrarle a las personas cuán bueno es su método.
Creo que una buena forma de colar los principios de TDD en un producto existente es comenzar a escribir pruebas unitarias para detectar errores. De esta forma, lentamente comenzará a construir un conjunto de pruebas unitarias para las pruebas de regresión que se convierten en una parte integral del proyecto, especialmente si puede hacer que se ejecuten como parte de su proceso de compilación.
El único obstáculo será que el código existente podría ser resistente a las pruebas, pero esa es solo otra excusa para hacer algunas refactorizaciones.
Una vez que la gente comienza a darse cuenta de los beneficios, el impulso crecerá, pero debe ser pionero en el camino.
Un gran desafío con TDD que se presenta "de abajo hacia arriba" es que, cuando se llega al límite (como inevitablemente ocurre cuando se acerca el plazo), la administración va a desestimar el énfasis en las pruebas: "Nosotros no podemos darnos el lujo de probar! ¡Tenemos que terminar el proyecto! "
Por supuesto, esta es la situación (vencimiento del plazo, retraso significativo, progreso no cumplido con promesas, lo que lleva a prioridades y tareas rápidamente cambiantes) donde los beneficios de TDD realmente entran en juego. La administración lo sobrepasa, el El proyecto/iteración comienza a desmoronarse en la misma vieja, y la administración mira hacia atrás y dice "Probamos TDD y no sirvió de nada."
Si bien no puedo decir qué va a trabajar, te puedo decir algunas cosas que definitivamente no va a funcionar y debe ser evitado:
Voy a escribir el código, se escribe la prueba
Este siempre aparece al principio. la gente asume que ya que eres tan entusiasta acerca de la prueba, debe ser el que escribir las pruebas. Esto no funciona en absoluto y se pierde el punto.
Usted escribió la prueba que se está rompiendo, por lo que debe arreglarla.
Si comienza a escribir pruebas para su código, inevitablemente alguien más romperá esas pruebas. Luego, si les pide que lo solucionen, a menudo dirán que es su responsabilidad. No se trata necesariamente de ser un imbécil, simplemente podría ser que no entienden el proceso. Aquí es donde necesitarás una copia de seguridad de administración.
Voy a comenzar y todos seguirán.
Como han dicho otros, TDD sin soporte administrativo es muy difícil. Si hay desarrolladores que no "beben Cool-Aid", estarán rompiendo constantemente tus pruebas y no te importarán. Si no puede hacerles creer, entonces necesita que la administración les diga que es su trabajo.
Lo que al final me dio la vuelta fue ver el colapso de un proyecto debido a demasiados errores. Me convenció de que estaba haciendo algo fundamentalmente equivocado. Un poco de investigación me llevó a las pruebas automáticas y, con un poco de determinación, aprendí lo básico. Tal vez hablar con tus colegas desarrolladores sobre proyectos similares (todos tenemos al menos uno ...) los ayudará a darse cuenta de que tal vez quieran probar algo nuevo.
Predicar con el ejemplo:
¿Alguna otra sugerencia? ¿Libros? ¿Entrenadores? ¿Comadreja? –