unit testing - unitarias - Inicio de prueba de la unidad en un proyecto GRANDE
pruebas unitarias php (6)
Falta de experiencia en escribir UnitTests / TDD
Creo que este es el más significativo.
El consejo estándar es comenzar primero a escribir pruebas unitarias para todo su nuevo código, de modo que aprenda a probar la unidad antes de intentar probar el código existente. Creo que este es un buen consejo en teoría, pero difícil de seguir en la práctica, ya que la mayoría de los trabajos nuevos son modificaciones de los sistemas existentes.
Creo que estarás bien atendido al tener acceso a un "coach de jugadores", alguien que podría trabajar en el proyecto con tu equipo y enseñarles las habilidades en el proceso de aplicarlos.
Y creo que estoy obligado por ley a pedirte que Michael Feather trabaje eficazmente con Legacy Code .
¿Alguien puede recomendar algunas de las mejores prácticas sobre cómo abordar el problema de comenzar con UnitTest una gran CodeBase existente? Los problemas que estoy enfrentando incluyen:
- ENORME base de código
- CERO UnitTests existentes
- Alto acoplamiento entre clases
- OM complejo (no puedo hacer mucho aquí, es un dominio comercial complejo)
- Falta de experiencia en escribir UnitTests / TDD
- Dependencia de la base de datos
- Dependencias de fuentes externas (servicios web, servicios WCF, NetBIOS, etc.)
Obviamente, entiendo que debería comenzar con la refacturación del código, para hacerlo menos acoplado y más comprobable. Sin embargo, hacer tal refactorización es arriesgado sin UnitTests (Chicken and Egg, anyone?).
En una nota al margen, ¿recomendaría comenzar la prueba de refactorización y redacción en las clases de dominio, o en las clases de nivel (registro, utilidades, etc.)?
Bruto. Tuve que lidiar con esto también. Creo que lo mejor que puede hacer es apoyarse en herramientas desagradables que probablemente no quiera usar (como NUnitAsp) al principio, para probar el código existente. Luego puede comenzar a refactorizar, mientras que esas herramientas evitan que su base de código se desmorone.
Luego, a medida que refactoriza, escriba pruebas de unidad más lógicas en las nuevas piezas comprobables que está creando y retire gradualmente las pruebas originales.
Buena suerte con esto ... Dado que tienes poca experiencia con las pruebas de unidad de escritura, te recomiendo que primero trates de obtener al menos alguna experiencia. De lo contrario, es probable que abandone las pruebas TDD / unidad y tal vez introduzca nuevos errores en el sistema que está intentando probar. La mejor manera de ganar experiencia es encontrar a alguien con experiencia que pueda ayudarlo.
Hay buenos consejos en el libro Manage it! por Johanna Rothman.
También podría recomendar lo siguiente:
- Utilice la prueba de la unidad en el nuevo código fuente generado
- Crear prueba unitaria para detectar errores
- Crear prueba unitaria para la parte más arriesgada de la aplicación
- Crea una prueba unitaria para la parte más valiosa de la aplicación.
- Si el acoplamiento es demasiado alto, cree pruebas que son más pruebas de módulo o integración pero automatizadas .
Una prueba de una sola unidad no ayudará. Pero es necesario para comenzar. Después, habrá una prueba unitaria de la parte más arriesgada de la aplicación y eso ayudará a prevenir errores en esos segmentos. Cuando llegues a este punto, la mayoría de los desarrolladores se darán cuenta de cuán útiles son las pruebas unitarias.
Primero, secundé la recomendación "Trabajar eficazmente con código heredado" que dio Jeffrey Frederick.
Como indicó en la pregunta, no puede cambiar su código porque actualmente no tiene pruebas de unidades disponibles para detectar regresiones, y no puede agregar pruebas de unidad porque su base de código no es susceptible de prueba por la unidad. En esta situación, puede crear pruebas de caracterización : pruebas automáticas de extremo a extremo que lo ayudarán a detectar cambios en el comportamiento externo de su software. Una vez que estén en su lugar, puede comenzar a modificar lentamente el código.
Sin embargo, poner a prueba su ENORME base de códigos es un esfuerzo enorme, muy arriesgado, y probablemente quemarás al equipo al hacerlo, ya que tendrán que realizar grandes esfuerzos con una baja recompensa en términos de cobertura de prueba. Poner a prueba toda la base de códigos es un esfuerzo sin fin.
En su lugar, desarrolle una nueva capacidad a partir de la base de códigos , para que no lo obstaculice. Una vez que el nuevo código esté completamente probado, integrelo en la base de códigos.
También intente crear pruebas unitarias cada vez que solucione un problema en la base de códigos. Será difícil los primeros tiempos, pero será más fácil una vez que tenga un entorno de prueba de la unidad listo para ser configurado.
No resolverás esto por tu cuenta. Hay mucha persuasión necesaria. Así que quiero darte este hilo, donde se dan mucha información y sugerencias para una buena argumentación: ¿cómo convencer a otros para que escriban pruebas unitarias?
Solo todo el equipo puede crear un gran tamaño de pruebas unitarias.