IMPLEMENTACIÓN DE LA METODOLOGÍA
TEST DRIVEN DEVELOPMENT EN EL
DESARROLLO DE UN PROTOTIPO DE SISTEMA
DE CONTROL DE INVENTARIO
IMPLEMENTATION OF THE TEST DRIVEN DEVELOPMENT
METHODOLOGY IN THE DEVELOPMENT OF A PROTOTYPE
INVENTORY CONTROL SYSTEM
Angel Geovanny Cudco Pomagualli
Universidad de las Fuerzas Armadas, Ecuador
pág. 3282
DOI: https://doi.org/10.37811/cl_rcm.v8i3.11552
Implementación de la Metodología Test Driven Development en el
Desarrollo de un Prototipo de Sistema de Control de Inventario
Angel Geovanny Cudco Pomagualli
1
agcudco@espe.edu.ec
https://orcid.org/0000-0003-4825-650X
Universidad de las Fuerzas Armadas – ESPE
Ecuador
RESUMEN
Actualmente, los sistemas de información están presentes en todos los aspectos de nuestra vida, y las
pequeñas y medianas empresas no son la excepción. Sin embargo, muchas aún carecen de un sistema
eficiente y confiable para administrar su información. Este trabajo se centra en la metodología Test
Driven Development (TDD), con el objetivo de identificar sus ventajas en la construcción de sistemas.
TDD es una metodología de desarrollo de software basada en pruebas para guiar el proceso. Los
resultados muestran que TDD, integrada en el framework JUnit, no solo cubre el testing de la aplicación,
sino que también promueve un diseño óptimo y eficiente. Esto mejora la codificación del software,
resultando en un código más tolerante al cambio, robusto y seguro. Tras analizar las ventajas de TDD
y los principios de Scrum, se desarrolló e implementó un prototipo de sistema de control de inventario
utilizando Java SE y MySQL. Este prototipo permitirá optimizar los procesos de compra, venta y control
de productos de cualquier PYME.
Palabras clave: sistemas de información, test driven development (TDD), desarrollo de software, junit,
SCRUM
1
Autor principal.
Correspondencia: agcudco@espe.edu.ec
pág. 3283
Implementation of the Test Driven Development Methodology in the
development of a prototype Inventory Control System
ABSTRACT
Nowaday, information systems are present in all aspects of our lives, and small and medium-sized
enterprises are no exception. However, many still lack an efficient and reliable system to manage their
information. This work focuses on the Test Driven Development (TDD) methodology, with the aim of
identifying its advantages in system construction. TDD is a software development methodology based
on testing to guide the process. The results show that TDD, integrated into the JUnit framework, not
only covers application testing but also promotes optimal and efficient design. This improves software
coding, resulting in code that is more tolerant to change, robust, and secure. After analyzing the
advantages of TDD and the principles of Scrum, a prototype inventory control system was developed
and implemented using Java SE and MySQL. This prototype will optimize the processes of purchasing,
selling, and controlling products for any PYME.
Keywords: information systems, test driven development (TDD), software development, Junit, SCRUM
Artículo recibido 20 abril 2024
Aceptado para publicación: 25 mayo 2024
pág. 3284
INTRODUCCIÓN
Garantizar la calidad de los productos de software y mejorar la productividad a lo largo de todo el ciclo
de vida, desde el inicio del desarrollo hasta las etapas de mantenimiento, representa uno de los desafíos
más significativos. En la actualidad, los requisitos son más volátiles que nunca, lo que potencialmente
conlleva la introducción de numerosos errores. Estos errores pueden causar que las funcionalidades
previamente implementadas comiencen a fallar y que aparezcan numerosos "bugs" durante la fase de
mantenimiento (Vaca et al., 2014).
A menudo, los equipos de desarrollo de proyectos de software centran su atención en la arquitectura del
software y en la adopción de nuevas tecnologías, dejando de lado la importancia de una metodología
de trabajo adecuada. Tanto las metodologías tradicionales como las ágiles tienen el propósito de guiar
al desarrollador desde la fase inicial hasta la fase de mantenimiento.
El Desarrollo Guiado por Pruebas (TDD), una técnica fundamental en el ciclo de desarrollo, permite a
los desarrolladores analizar, modificar y refactorizar el código fuente sin el temor de afectar las
funcionalidades existentes, ya que cada una de ellas está asociada a una prueba que debe superarse.
En este trabajo, se llevó a cabo la implementación de un prototipo de sistema para el control de
inventario de cualquier PYME utilizando la metodología TDD. Esta metodología destaca por escribir
la menor cantidad posible de código para obtener el resultado deseado, y fue implementada a través del
framework JUnit.
METODOLOGÍA
El trabajo se llevó a cabo desde un enfoque cuantitativo y con un diseño de tipo cuasi experimental. Su
principal foco es la aplicación de la metodología Test Driven Development (TDD) dentro del marco de
trabajo Scrum, para evaluar la calidad del código en las operaciones CRUD (Crear, Leer, Actualizar,
Eliminar). Se logró que el código tenga una legibilidad adecuada, esté libre de duplicaciones y
redundancias, y mantenga un alto nivel de mantenibilidad. El objetivo principal es lograr un código
limpio y funcional que se integre de manera efectiva en el contexto ágil de desarrollo proporcionado
por Scrum.
Para el desarrollo del prototipo se tomaron como referencia un ciber, un tienda de ropa y mini-mercado,
y se establecieron los siguientes roles:
pág. 3285
Tabla 1. Roles del sistema.
Rol
Descripción
Responsabilidades
Administrador
Persona responsable de
administrar sistema.
Gestiona el personal de la empresa, compras,
ventas, administrar el almacén, realizar el control
de productos y generar informes, reportes
gráficos y en formato pdf.
Vendedor
Persona que se encarga
del área de ventas.
Gestionar las ventas.
Fuente: Autor
Finalizada la especificación de requisitos de acuerdo a su prioridad y considerando la complejidad de
cada uno, se procedió a transformarlos en historias de usuario. Tras las reuniones con los voluntarios y
el análisis de los resultados, se identificaron treinta y siete requisitos, que se desglosan en ocho historias
técnicas y veintinueve historias de usuario. La siguiente tabla detalla las historias de usuario e historias
técnicas utilizadas en el desarrollo del sistema.
Tabla 2. Historias de usuario y técnicas
Código
Descripción
HT-01
Establecer los requerimientos del sistema
HT-02
Establecer la arquitectura del sistema
HT-03
Diseño de Estándar de Codificación
HT-04
Diseño del estándar de interfaz
HT-05
Realizar la Base Datos (Modelo entidad relación, lógico, físico, script
diccionario de datos)
HU-01
Ingresar categoría
HU-02
Modificar categoría
HU-03
Agregar vigencia de categoría
HU-04
Gestión productos
HU-05
Agregar productos
HU-06
Modificar productos
HU-07
Buscar para el módulo almacén
HU-08
Establecer vigencia de producto
HU-09
Reportes para módulo almacén
HU-10
Crear sesión de usuarios
HU-11
Gestionar roles
HU-12
Asignar funcionalidad de acuerdo con el rol de usuario
pág. 3286
HU-14
Buscar y visualizar usuarios empleados de la empresa
HU-15
Gestionar proveedores
HU-16
Gestionar compras a proveedores
HU-17
Consultar compras por fecha, mes
HU-18
Buscar proveedores
HU-19
Historial de precios
HU-20
Reportes para el módulo proveedores
HU-21
Gestionar clientes
HU-22
Gestionar venta
HU-23
Consultar ventas por día, fecha, mes
HU-24
Reportes para el módulo ventas
HU-25
Administrar caja
Hu-26
Historial de caja
HU-27
Generar Inventario
HU-28
Resumen de saldos y movimiento de productos.
HU-29
Graficas estadísticas de compras y ventas.
HT-07
Capacitación de usuarios
HT-08
Documentación final del Sistema
Posteriormente se estableció el Sprint Backlog.
Tabla 3. Sprint Backlog
ID
Descripción
Esfuerzo
SPRINT 1
60
HT-01
Establecer los requerimientos del sistema
18
HT-02
Establecer la arquitectura del sistema
18
HT-03
Diseño de Estándar de Codificación
6
HT-04
Diseño del estándar de interfaz
18
SPRINT 2
60
HT-05
Realizar la Base Datos (Modelo entidad relación, lógico, físico, script
diccionario de datos)
12
HU-01
Ingresar categoría
12
HU-02
Modificar categoría
12
HU-03
Agregar vigencia de categoría
12
HU-04
Gestión productos
12
pág. 3287
ID
Descripción
Esfuerzo
SPRINT 3
60
HU-05
Agregar productos
12
HU-06
Modificar productos
12
HU-07
Buscar para el módulo almacén
12
HU-08
Establecer vigencia de producto
12
HU-09
Reportes para modulo almacén
12
SPRINT 4
60
HU-10
Crear sesión de usuarios
18
HU-11
Gestionar roles
12
HU-12
Asignar funcionalidad de acuerdo con el rol de usuario
12
HU-13
Activar estado de vigencia de la funcionalidad asignada
12
HU-14
Buscar y visualizar usuarios empleados de la empresa
6
SPRINT 5
60
HU-15
Gestionar proveedores
12
HU-16
Gestionar compras a proveedores.
12
HU-17
Consultar compras por fecha, mes.
12
HU-18
Buscar proveedores
6
HU-19
Historial de precios
6
HU-20
Reportes para el módulo proveedores
12
SPRINT 6
60
HU-21
Gestionar clientes
12
HU-22
Gestionar venta
24
HU-23
Consultar ventas por día, fecha, mes
12
HU-24
Reportes para el módulo ventas
12
SPRINT 7
60
HU-25
Administrar caja
24
HU-26
Historial de caja
12
HU-27
Generar Inventario
24
SPRINT 8
60
HU-28
Resumen de saldos y movimiento de productos
30
HU-29
Graficas estadísticas de compras y ventas
30
SPRINT 9
60
HT-07
Capacitación de usuarios
18
pág. 3288
ID
Descripción
Esfuerzo
HT-08
Documentación final del Sistema
24
Finalizada la especificación de requisitos se procedio a la codificación mediante el patron MVC, a
continuación, se detallan los hitos más importantes:
Tabla 4. Estándar de codificación.
Componente
Nombre
Descripción
Clases
categoriaController
Nombre de la clase y luego nombre del módulo al que
pertenece.
Variables
String categoría
Tipo de variable y luego asignar un nombre al atributo
Métodos
categoriaBuscar ()
Nombre de la clase seguido del nombre de método.
La base de datos se diseñó conforme a los requisitos e historias de usuarios. En la siguiente figura, se
presenta el modelo físico, donde se pueden identificar las entidades, atributos y sus relaciones.
Figura 1. Diagrama de bases de datos
Finalizada la especificación de las historias de usuario y los diseños del software, se procedió a la
codificacióny a expresar estas funcionalidades en códigos de prueba. El Framework JUnit proporciona
la API necesaria para llevar a cabo pruebas unitarias de cada requisito. Cada prueba permite evaluar si
pág. 3289
un método dentro de un módulo funciona correctamente y verificar el comportamiento de los métodos
de dicho módulo.
Para realizar las pruebas unitarias a las funciones del sistema, es necesario crear la clase de la entidad a
analizar. Siguiendo el proceso de implementación del marco de trabajo TDD, la prueba que se
implementa en las fuentes del proyecto debe fallar como primer paso. Luego se realiza la refactorización
y se corrigen los inconvenientes presentados.
A continuación, se presenta como ejemplo la prueba "Agregar productos", seguida de un detalle de cada
uno de los pasos hasta obtener la ejecución satisfactoria. El proceso para ejecutar una prueba con la
técnica TDD es el siguiente.
Figura 2. Prueba unitaria para el método "agregar productos"
Nótese que dentro de la prueba unitaria se incluye la etiqueta @Test y el método assertEquals los
mismos que indican que se está aplicando un test unitario. La ejecución de las pruebas consiste en
verificar si pasan o no, cabe mencionar que no siempre las pruebas se ejecutarán satisfactoriamente, ya
que el objetivo de TDD es hacerlas fallar.
pág. 3290
Figura 3. Resultado de la ejecución de las pruebas unitarias
Para corregir el error encontrado durante la ejecución del test, es necesario localizar la clase Java y la
línea específica donde está mal codificada. En este caso, el problema se soluciona agregando un bloque
de excepciones try y catch dentro del método agregarProducto de la clase ProductoDAO.
Figura 4. Refactorización del método Agregar en la clase ProductoDAO
De forma similar se modifica el código de la prueba unitaria, agregando una excepción y las cláusulas
de try y cacth.
Figura 5. Refactorización de la prueba unitaria