Estoy trabajando con un gran sistema heredado. Puedo depurar y agregar funciones, pero no sé cómo probar mi código. ¿Qué debo hacer?

Answer 1

Soy ingeniero de control de calidad.

Primero, aprenda sobre el tipo de prueba:

• Examen de la unidad
• Prueba funcional
• Pruebas de integración

Otra idea interesante es: las pruebas son especificaciones.
Eso significa que las pruebas deben escribirse antes del código de característica.

Además, la integración continua es imprescindible en estos días. Permite iteraciones más rápidas y gana mucho tiempo. (incluso en proyectos de una persona)

Si eres más de una persona, ¡uno escribe las pruebas y el otro la implementación sin mirar las pruebas! Asegura que ambos entendieron la solicitud original.

Como ingeniero de control de calidad, escribí casos de pruebas “secretas” que deben pasar incluso cuando las métricas de los proyectos son ecológicas.

Además de las pruebas, hay una revisión de código. Incluso el desarrollador junior puede detectar el “código de culo inteligente” y otras construcciones extrañas.

Estos son los conceptos básicos.

Además, para tener buenas pruebas, debe tener buenas especificaciones. No significa un archivo grande con muchos diagramas UML y palabras sabias.

Significa casos de uso e historias de usuarios.

Ahora lo mejor es que puedes hacer BDD. (Desarrollo conducido por el comportamiento)
En ese caso, sus pruebas se verán así (gerschin):
Como usuario
Suponiendo que inicie sesión
Y suponiendo suficiente fondo
Cuando apuesto 10 € a un caballo
Y gana con una cotización 1.6
Entonces consigo 6 €

Y con esto, tendrás historias de usuario + base de tus pruebas 😉

Answer 2

Primero algunos supuestos:

• No existen pruebas automatizadas para la solución actual, y prácticamente no existen pruebas manuales.
• El sistema heredado no fue diseñado para ningún grado de prueba (todo estático, estado mutable en todo el lugar).
• La aplicación tiene muchas dependencias, todas entretejidas en el código.
• La aplicación está terriblemente escrita.
• Tiene suficiente influencia dentro de la organización para hacer algunos cambios importantes y hacer que el resto del equipo de Legacy lo acompañe en este viaje.

Ese último es importante. Si no lo hace, le recomendaría que continúe.

Tienes dos caminos por los que puedes bajar para mejorar la vida, no son mutuamente excluyentes, así que si tienes los recursos, haz ambos.

El primero es construir una prueba básica de integración de pila completa. En este uso, herramientas como Vagrant para construir un entorno virtualizado completo y hacer pruebas de caja negra. Convierta el mundo en un estado conocido, toque un recurso y valide los resultados. Estas serán pruebas grandes, lentas y feas, pero se pueden escribir con solo pequeños cambios en el código fuente existente y pueden darle un grado de confianza de que no ha roto nada importante. No vaya a escribir pruebas para todo lo que está bajo el sol, solo clave una alrededor de las características en las que trabaja.

El segundo es romper características. Cuando comience a trabajar en una nueva función, cree un nuevo servicio (aplicación completamente separada) que maneje esa función y haga que ese servicio se llame heredado. El nuevo código se puede escribir con una influencia mínima de la base de código Legacy, por lo que se puede diseñar desde el principio para que sea comprobable.

Con el tiempo, más y más de la plataforma Legacy se dividirá en pequeños servicios, el objetivo final sería tener la plataforma Legacy como intermediario entre estos servicios (nunca sucederá, pero puede soñar).

Qué no hacer: Inicie un proyecto para “reescribir Legacy”. Será tentador, pero a menos que lo haga con mucho cuidado (ver arriba), tendrá algo que no podrá liberar hasta el final, momento en el cual sus competidores habrán agregado un montón de nuevas características mientras que todo lo hubiera hecho. relanzó lo mismo que tenía antes.

Answer 3

¿Existe un conjunto de pruebas para la funcionalidad actual? Debería haber. Ejecute estos. Esto se denomina “prueba de regresión”, asegurándose de que no haya roto nada que haya funcionado anteriormente. Luego agregue pruebas para nuevas funcionalidades. Agregue estas pruebas al conjunto de pruebas. Me doy cuenta de que es un poco simplista, pero es la idea básica. Las pruebas deben desarrollarse junto con el desarrollo, ambas deben utilizar los documentos de requisitos como base.