Blog

El ciclo de trabajo del TDD, Test Driven Development para SAP

[fa icon="calendar"] 30/08/2016 por Equipo de Redacción Linke IT

Equipo de Redacción Linke IT

Test driven development para SAP


Pongámonos en marcha hoy con lo relacionado con el Test Driven Development, o lo que también conocemos en castellano como “desarrollo guiado por pruebas de software” y su siglas originales TDD. Este proceso es común en el sector de la ingeniería de software y está representado por la realización de dos procesos distintos:

  • Uno de ellos recibe el nombre de Test First Development (las pruebas primero)
  • El otro es Refactoring (refactorización)

El correcto aprovechamiento de ambos da como resultado una práctica muy extendida en el sector profesional y con capacidad para proporcionar un gran rendimiento. 

 

Cómo funciona el Test Driven Development para SAP

Teniendo lo anteriormente citado en cuenta, hay que partir del concepto que el primer paso se basará en escribir una prueba y comprobar hasta qué punto se está proporcionando un buen rendimiento con ella. Lo natural es que haya fallos hasta que se actualiza el código para que no existan errores.

Después, cuando todo está ajustado y solucionado, realizamos la refactorización de la cual hemos hablado. Con ella, el código se queda como definitorio y como reflejo del trabajo y los cambios realizados.

Al final, nos debe que quedar en las manos un código único que no producirá problemas y que tendrá aquello necesario para sacarle partido en el momento de poner el software en funcionamiento. Por otra parte, tendremos que valorar que, si el sistema en el que trabajamos no nos aporta un cierto volumen de flexibilidad, no podremos conseguir un resultado satisfactorio.

Las pruebas se realizan de manera automática, no manual, así que todo tiene que ser capaz de fluir de una manera muy libre para que el código demuestre que es funcional en su totalidad. A esto hay que sumar que el resultado llega a ser más ligero y eficiente, porque de una manera relacionada nos estamos empujando a evitar problemas y errores que cometíamos en el pasado.

 

Ciclo de trabajo

Ya puestos en faena nos vamos a encontrar con que el desarrollo guiado por pruebas de software se lleva a cabo siguiendo unos pasos muy establecidos y que hacen que la experiencia sea más automatizada.

Elegir el requisito

Lo primero que hacemos es elegir el requisito. Dado que hay muchas opciones entre las que elegir, debemos intentar que sea el que más encaje en nuestro caso concreto. Todo dependerá de nuestro caso específico, de las expectativas y también de la facilidad de implementación. Por eso habrá que decidirlo pensando bien cada uno de los factores.

Escribir una prueba

Luego escribiremos una prueba teniendo en cuenta el requisito de origen que hemos seleccionado. Antes de comenzar a trabajar en ella, es imprescindible ser conscientes de lo que se nos está solicitando. Habrá que valorar requisitos y especificaciones antes de elegir una prueba en concreto.

Verificación de la prueba

Después verificamos que la prueba es errónea, llevamos a cabo la escritura de la implementación de una forma simplificada (siempre la más fácil posible) y ejecutamos de forma automática las pruebas. Ahora el sistema automatizará el proceso para mayor satisfacción.

Refactorización

Como decíamos antes, tendremos que eliminar el código duplicado que haya quedado y limpiarlo todo para dejarlo lo más suave posible. En este caso lo que necesitamos implementar es la refactorización. Iremos borrando y probando hasta dar con la versión adecuada.

Actualización de requisitos

Acabamos con la necesaria actualización de los requisitos. El que ya se haya implementado se eliminará y, si nos hemos encontrado con alguno extra, lo añadiremos, puesto que el trabajo posiblemente esté lejos de haber terminado. Cuanto más de la mano tengamos este sistema, más nos aseguraremos de que todo rendirá de manera fluida a la hora de la verdad.

 

Aunque es difícil aplicar el TDD en algunos contextos -como cuando estamos trabajando con bases de datos o GUIs-, lo cierto es que es una práctica con muchas ventajas. Por ejemplo, nos ahorraremos multitud de situaciones en las que no nos queda otro remedio que meternos en el debugger para ver qué es lo que puede haber salido mal en el servidor.

Por otro lado, también es algo que viene muy bien para los desarrolladores, que además de realizar este tipo de gestión, cuentan con la responsabilidad de llevar a cabo herramientas de software. En esos casos se notan los beneficios, mientras que también es una práctica recomendable para los especialistas que quieren aumentar la agilidad de los desarrollos.

Si te ha interesado este post, quizás también te interese esta guía gratuita en PDF:

Guía: Todo lo que necesitas saber sobre SAP en AWS

Categorías: SAP