Hmmm Escribí algo en Pro * C (que creo que es lo mismo que Pro-C) hace unos 20 años. ¿Es su “industria” quizás el IRS? (Como eres anónimo, ni siquiera puedo estar seguro de que estés en los EE. UU. …)
De todas formas….
La idea principal que me viene a la mente es lo que se conoce como desarrollo impulsado por el comportamiento. Escriba pruebas de aceptación , basadas en el comportamiento del sistema anterior. Para cada característica que desee transferir, escriba una prueba de aceptación (preferiblemente ejecutable de forma automática en lugar de manual), que fallará hasta que el nuevo sistema tenga esa característica. (¡Haga esto también para todas las funciones nuevas !) Verifique (manualmente si es necesario) que el sistema antiguo se comporta de esa manera. Idealmente, tiene un documento de requisitos lleno de características organizadas que pueden convertirse en pruebas automáticas.
- ¿Cuáles son los cursos que debes tomar como emprendedor?
- Cómo enfocarme solo en una de mis 3 startups tecnológicas
- ¿Cómo es FMS Delhi para el emprendimiento?
- ¿A dónde voy para obtener capital para la próxima novedad en cosméticos?
- ¿Deberían los desarrolladores y empresarios dejar de intentar crear el próximo Facebook?
(Técnicamente, eso es solo escribir pruebas primero, no necesariamente un desarrollo impulsado por el comportamiento. El paso que falta es dejar que las pruebas influyan en cómo se desarrolla, pero ese es un proceso mucho más complicado de lo que quiero detallar aquí. Prueba- primero sigue siendo mejor que test-after, que es infinitamente mejor que test-never!)
También puede aplicar pruebas unitarias a los elementos de nivel inferior a medida que avanza, y escribir las pruebas primero en un proceso análogo llamado Desarrollo impulsado por pruebas.
Hay muchos consejos sobre exactamente qué probar y cómo, por lo que no entraré en detalles al respecto, especialmente porque algunos de ellos son conflictivos. Tampoco puedo recomendar herramientas específicas sin saber con qué pila de tecnología está trabajando para el nuevo sistema. Sin embargo, les daré un consejo que me encontré hace un par de años que me ha ahorrado un poco de trabajo decente y ha hecho que mis suites de prueba funcionen mucho más rápido:
No tiene que tener pruebas completas de nivel BDD (es decir, pruebas que demuestren que el sistema muestra una cosa determinada al usuario ) para cada función. En cambio, puede tener una prueba de nivel BDD que demuestre que el sistema muestra correctamente los resultados de una prueba de nivel inferior (como una prueba de unidad en un método de una clase), y luego realizar más pruebas allí . Esta es una victoria porque las pruebas de nivel inferior tienden a ser mucho más rápidas . Cuanto más rápida sea la prueba, menos tiempo perderá esperando (algunos han dicho que la prueba es la nueva compilación, como en xkcd), más fresca está en la mente del desarrollador que el trabajo actual es cuando finaliza la prueba, para poder continuar trabajando en Es más rápido.
Por ejemplo, suponga que está probando una “epopeya” (conjunto de características relacionadas) que dice que el sistema permite al usuario enumerar sus widgets, incluida la búsqueda por color y tamaño. Puede conducir la función que dice que el usuario puede enumerar sus widgets sin buscar, el que busca sus widgets azules y ve esos pero no otros, y el que busca sus widgets azules pero ve un mensaje de error eso dice (correctamente) que ella no tiene ninguno. Eso es suficiente para demostrar la conexión entre la generación de la lista (con parámetros de búsqueda opcionales) y la pantalla. Luego puede probar la generación de la lista para verificar que puede buscar por tamaño, por tamaño y color al mismo tiempo, etc. (Es posible que desee realizar algunas pruebas de nivel BDD para demostrar que los controles de la interfaz de usuario que le permiten intentar hacer eso, en realidad aparece, pero no para probar la exactitud de los resultados ).
En cualquier caso, ¡bien por pensar en probar por adelantado! Demasiadas personas lo dejan por una idea de último momento.