La fluctuación, la jubilación y la rotación laboral hacen necesario que los conocimientos técnicos y comerciales se transfieran a otros desarrolladores ABAP.
Esto no sólo cuesta tiempo y energía a los desarrolladores restantes que se ocupan de estos temas, sino que también conlleva el riesgo de que se pierdan gradualmente conocimientos detallados. Además, a los nuevos desarrolladores a menudo les resulta difícil comprender una base de código evolucionada y asumir las tareas iniciales de forma cómoda y segura. En muchos casos, estos desarrolladores principiantes necesitan el (escaso) tiempo de los desarrolladores experimentados para aprender, lo que reduce aún más la productividad del equipo. Dado que la documentación basada en archivos a menudo no puede mantenerse al día con el mantenimiento y el desarrollo posterior, es más eficiente y sostenible mantener y compartir el conocimiento sobre casos de negocios y su implementación con diagramas de diseño y pruebas automatizadas. Las pruebas legibles permiten no sólo una verificación continua del código sino también una documentación ejecutable de una aplicación.
Pero, ¿qué hace que una prueba sea legible? Los casos de prueba a menudo dependen en gran medida de los datos de prueba. Por ejemplo, una clase que se está probando puede importar datos de prueba, seleccionarlos de la base de datos o recibirlos de un doble de prueba. En todos estos casos, los datos de prueba deben crearse de antemano. En el caso de ABAPesta acumulación de datos de prueba generalmente significa seleccionarlos de un contenedor de datos de prueba o crearlos ad hoc usando el operador VALOR. Sin embargo, ninguna de estas alternativas es legible, porque ambas operan a nivel de campo y, por lo tanto, sobrecargan al lector de la prueba con nombres y detalles técnicos cuestionables.
¿Qué sucede si se necesitan más métodos de prueba? Esto significa que muchos desarrolladores copiarán las declaraciones de datos de prueba complejas y simplemente editarán lo que es diferente en el nuevo caso de prueba. Si bien esta duplicación le permite escribir pruebas rápidamente una vezle impide leerlos y mantenerlos rápidamente a lo largo del tiempo, ya que la prueba necesita actualizarse. Esto es particularmente crítico cuando se desea la propiedad del código compartido y los traspasos ocurren con frecuencia.
Puede abordar estos desafíos con clases de datos de prueba, es decir, la representación de datos de prueba orientada a objetos. Estos datos de prueba pueden ser jerarquías de datos de personalización, transaccionales o maestros, como muestra la siguiente figura. Esta figura indica además cómo los métodos de prueba del conjunto de pruebas crean objetos de datos de prueba para configurar las pruebas.objetos dobles y llamar al método bajo prueba.
Las clases de datos de prueba ofrecen los siguientes beneficios:
- Sus métodos introducen nombres específicos de aplicaciones y ocultan detalles técnicos, como la asignación de un identificador obligatorio (pero no revelador).
- Si se definen globalmente, las clases de datos de prueba hacen que los métodos de prueba sean legibles y la acumulación de datos de prueba sea reutilizable.
- Permiten que un equipo cuyo código de producto esté dominado por módulos de funciones adquiera experiencia práctica con la programación orientada a objetos en un entorno seguro.
Mi E-Bite de SAP PRESS Clases de datos de prueba para ABAP presenta este concepto estandarizado e independiente del lenguaje con muchos ejemplos de código para escenarios de prueba comunes. Compruébalo y prepara a tu equipo para cualquier cambio que se avecine.
