Lección 142: ¿Por qué necesitamos automatizar la build y las pruebas?

Hubo una época "antes de CI/CD" en la que los desarrolladores ejecutaban las pruebas a mano, movían ficheros entre servidores y se preguntaban por qué la aplicación que "funcionaba en mi máquina" daba errores en producción. Aquellos tiempos eran duros. Pero, por suerte, a los programadores no les gusta perder el tiempo en tareas aburridas y repetitivas. Así que, usando un poco de ingenio y tecnología, inventaron la automatización de la build y de las pruebas. Ahora nosotros y otros desarrolladores podemos dedicar nuestro tiempo y energía a cosas más importantes, en vez de buscar el punto y coma perdido ; o espacios.

La automatización de la build y de las pruebas son pasos fundamentales hacia CI/CD. Pero, ¿para qué sirve todo esto? Vamos a verlo.

Automatización de la build

Build (build) — es el proceso de transformar tu código en un programa listo para ejecutar. Para aplicaciones Java normalmente significa convertir los archivos fuente .java en .class, y luego en un .jar o .war final.

Problemas de hacer la build a mano

Si tu proyecto es pequeño, hacer la build a mano no es tan grave. Bueno, la mayoría de las veces. Pero imagina un proyecto con cientos de clases, decenas de módulos y un montón de dependencias. ¿Vas a repetir esos pasos cada vez? ¡Qué pérdida de tiempo! Y los errores… estarán a la vuelta de la esquina.

¿Por qué automatizar la build?

La automatización de la build soluciona muchos problemas:

1. Ahorro de tiempo. En lugar de ejecutar comandos a mano, configuras el proceso una vez y el sistema lo hace por ti.
2. Repetibilidad. Cada build ocurre igual, minimizando el riesgo de errores humanos.
3. Gestión de dependencias. Las herramientas de build encuentran, descargan y enlazan las librerías necesarias automáticamente.
4. Integración con pipelines de CI/CD. Sistemas como Jenkins, GitLab CI o CircleCI pueden ejecutar la build automáticamente después de cada cambio en el código.

Herramientas para automatizar la build

Los desarrolladores Java viven seguros con unas cuantas herramientas excelentes. Seguro que ya las conoces.

• Maven — el favorito del mundo corporativo; pide que sigas un formato estricto, pero automatiza todo: desde la compilación hasta la generación de documentación.
• Gradle — una alternativa moderna a Maven, que ofrece más flexibilidad y encaja mejor con Kotlin.
• Ant — la herramienta de la vieja escuela, que aún se usa, aunque requiere más configuración manual.

Ejemplo de archivo pom.xml (Maven), que muestra la automatización de la build:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>awesome-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.0.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>17</source>
                    <target>17</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Este archivo construye automáticamente el proyecto, descarga las dependencias y compila el código.

Automatización de las pruebas

Las pruebas son como el control de calidad, pero en software. Compruebas que todo funcione como debe antes de que los usuarios lo vean.

En Java normalmente hablamos de tres tipos principales de pruebas:

1. Pruebas unitarias — prueban clases o métodos individuales.
2. Pruebas de integración — verifican cómo varios módulos funcionan juntos.
3. End-to-end (E2E) tests — prueban la aplicación completa, incluyendo la interacción con sistemas externos (por ejemplo, la base de datos).

¿Por qué automatizar las pruebas?

Porque hacer pruebas a mano es un infierno. Además, es lento. Un autotest puede ejecutar en un minuto lo que a un tester manual le llevaría horas. Además, cada autotest se ejecuta igual, eliminando el factor humano. Y otra ventaja: los tests se ejecutan con frecuencia (por ejemplo, en cada commit), lo que permite arreglar bugs rápidamente.

Herramientas para automatizar las pruebas

En el ecosistema Java hay muchas herramientas:

• JUnit — la herramienta principal para escribir y ejecutar tests.
• Mockito — librería para crear mocks y stubs.
• Spring Boot Test — conjunto de utilidades integradas en Spring Boot para probar services y controllers.

Ejemplo de un test unitario sencillo usando JUnit:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class CalculatorTest {

    @Test
    void testAddition() {
        Calculator calculator = new Calculator();
        int result = calculator.add(2, 3);
        assertEquals(5, result, "2 + 3 debe ser igual a 5");
    }
}

Integración de pasos automáticos en el pipeline de CI/CD

La automatización de la build y de las pruebas encaja muy bien en CI/CD:

1. Cada commit dispara el pipeline. Por ejemplo, el desarrollador hace cambios, los push a un repositorio y el pipeline se inicia automáticamente.
2. La build se ejecuta automáticamente. Herramientas como Jenkins lanzan el proceso de build y crean artefactos.
3. Las pruebas se ejecutan después de la build. Si se encuentra un problema, el pipeline se detiene y el desarrollador recibe una notificación.

Ejemplo de archivo .gitlab-ci.yml:

stages:
  - build
  - test

build:
  stage: build
  script:
    - mvn clean package

test:
  stage: test
  script:
    - mvn test

Ahora, con cualquier commit GitLab CI ejecutará automáticamente la build de Maven y las pruebas.

Ejemplo final: del código a producción

Cómo se ve esto en la práctica:

1. El desarrollador escribe nuevo código y lo pushea al repositorio.
2. CI/CD ejecuta un pipeline que:
   • Construye el proyecto con Maven.
   • Ejecuta las pruebas con JUnit.
   • Crea un artefacto (por ejemplo, un archivo .jar).
   • Despliega el artefacto en un entorno de pruebas.

Si todo va bien, los cambios llegan a producción.

Pasamos a la siguiente lección, donde empezaremos a configurar las herramientas de CI/CD para que todo funcione como la seda.