- Elena Recio Pérez
- Álvaro Vázquez Suárez
- Comprender los objetivos de medición relacionados con la caracterización y la evaluación de productos, procesos y recursos software.
- Comprender, aplicar y analizar técnicas de medición sobre entidades de productos software relacionados con conjuntos de pruebas de software
- Comprender, aplicar y analizar medidas relacionadas sobre entidades de proceso y recursos de prueba del software
En la práctica se va simular un pequeño desarrollo de un producto software para realizar mediciones sobre él. El objetivo es establecer un caso de estudio dummy que sirva para caracterizar y evaluar tanto el producto desarrollado como el proceso seguido. (a) Descripción del producto Dado un código de ejemplo del patrón diseño creacional Pool Object, se debe crear una batería de pruebas tal que las coberturas de sus clases sean del 100%. El código de las clases se puede obtener en el repositorio https://github.com/clopezno/poolobject. La batería de pruebas JUnit debe estar contenida en la clase ubu.gii.dass.test.c01.ReuseblePoolTest.java. (b) Descripción del proceso El proceso de desarrollo de la batería de pruebas se va a gestionar utilizando el control de versiones del sistema git proporcionado por Github (https://github.com ). Los pasos para gestionar el procesos son los siguientes:
- Cada miembro del equipo tiene que estar registrado en GitHub, Travis CI (opcionalmente se puede sustituir por Github actions) y Codecov.io.
- Uno de los miembros tiene que realizar un fork del repositorio donde se encuentra el código que se quiere probar https://github.com/clopezno/poolobject. El nuevo fork del repositorio tiene que ser público.
- Invitar al resto de miembros del equipo para que puedan participar en el proceso de desarrollo del conjunto de pruebas.
- Vincular el proyecto con Travis CI o Github actions, y Codecov.io. Actualizar los badgets (codecov y CI) de vuestro fichero README.md en el repositorio.
- Cada nuevo test realizado ejecutar un commit/push al repositorio del grupo. El texto del commit tiene que describir el caso de prueba añadido.
- Verificar el resultado de las pruebas en el workflow de integración continua y cómo la calidad del producto va mejorando con las sucesivas integraciones
¿Se ha realizado trabajo en equipo?
Sí, pero todos los commits salen a nombre de elena Recio ya que en el momento en el que lo realizamos a trvés de videollamada WhatsApp, Álvaro Suárez no disponia de ordenador para poder realizar la practica.
¿Tiene calidad el conjunto de pruebas disponibles?
Sí
¿Cuál es el esfuerzo invertido en realizar la actividad?
Unas 3-4 horas