Home

Autor: Miguel Ángel Jódar de la Torre Informe de Medición: Caso de Estudio Pool Object

1. Introducción y Objetivos Este documento recoge la caracterización y evaluación del producto software y el proceso colaborativo seguido para el desarrollo de una batería de pruebas unitarias.

Objetivo de Producto: Comprender y aplicar técnicas de medición sobre entidades relacionadas con pruebas e integración continua, alcanzando una cobertura cercana al 100%.

Objetivo de Proceso: Analizar medidas sobre entidades de proceso y recursos de prueba en un entorno colaborativo.

2. Descripción del Caso de Estudio Se ha trabajado sobre un código de ejemplo del patrón de diseño creacional Pool Object, el cual gestiona una colección de objetos reutilizables. El reto consistía en crear una batería de pruebas JUnit en la clase ReuseblePoolTest.java para garantizar la calidad del componente.

3. Respuestas a la Evaluación del Proceso A. ¿Se ha realizado trabajo en equipo?

Respuesta: Sí, se ha seguido una dinámica colaborativa gestionada mediante Git y GitHub.

Indicador Cuantitativo: Consultar el Historial de Commits del Repositorio. https://github.com/zcc1001/poolobject/commits/master/

Justificación: Los casos de prueba se distribuyeron entre los miembros (MigueJodar, etc.). Se puede observar que cada participante realizó al menos un commit cuyo mensaje coincide con la anotación @DisplayName del código.

B. ¿Tiene calidad el conjunto de pruebas disponibles?

Respuesta: La calidad es alta, validada por la cobertura total de las ramas y sentencias.

Indicador Cuantitativo: Enlace al informe de Codecov.

Justificación: Se ha alcanzado una cobertura cercana 100% en todas las clases (ReusablePool, Reusable, etc.). El conjunto de pruebas no solo valida el "camino feliz", sino también la gestión de excepciones como NotFreeInstanceException y DuplicatedInstanceException.

C. ¿Cuál es el esfuerzo invertido en realizar la actividad?

Respuesta: El esfuerzo se ha medido en términos de tiempo de desarrollo y actividad en el repositorio.

Indicador Cuantitativo:

Número de Commits: 66 commits totales.

Tiempo transcurrido: Desde el fork inicial hasta la última integración el 25/02/26.

Justificación: Se invirtieron sesiones de coordinación para el reparto de tests y resolución de conflictos técnicos con el entorno Maven.

D. ¿Cuál es el número de fallos encontrados en el código original?

Respuesta: Se detectaron varios fallos/problemas de diseño.

Justificación:

Estado del Singleton: Se detectó que el diseño del ReusablePool como Singleton dificulta la independencia de las pruebas, requiriendo un método de limpieza (@AfterEach) para evitar que un test contamine al siguiente.

E. ¿El proceso de integración continua realizado ha sido de calidad?

Respuesta: Sí, el flujo ha permitido detectar errores de compilación y regresiones de forma automática.

Indicador Cuantitativo: Historial de GitHub Actions. https://github.com/zcc1001/poolobject/actions

Justificación: Se configuró un fichero yml para ejecutar Maven en cada push. El proceso impidió integrar código que no compilaba (como el error de la anotación @AfterEach que detectamos) o que bajaba la cobertura por debajo del umbral establecido.

4. Stack Tecnológico Utilizado

IDE: VS Code (Codespaces)

Gestión de Dependencias: Maven.

Pruebas Unitarias: JUnit 5.

CI/CD: GitHub Actions y Codecov.io.