Pruebas de Integración: Uso de Mocks y Stubs en Java

Los dobles de prueba (pruebas de integración) son una técnica utilizada en las Arquitecturas Limpias para el desarrollo de software. Estas pruebas se enfocan en validar la interacción y la integración correcta entre los diferentes componentes del sistema. Aquí tienes un ejemplo de cómo se podrían implementar los dobles de prueba en el contexto de las Arquitecturas Limpias:

Supongamos que tenemos una aplicación que sigue la arquitectura limpia y consta de las siguientes capas: la capa de dominio, la capa de aplicación y la capa de infraestructura.

En la capa de dominio, tenemos una clase llamada UserService que es responsable de la lógica relacionada con los usuarios. Esta clase depende de un repositorio para acceder a los datos de los usuarios.

En lugar de utilizar directamente el repositorio real en las pruebas de integración, podemos crear un doble de prueba (mock) del repositorio. Este doble de prueba simula el comportamiento del repositorio real, pero en lugar de acceder a una base de datos, puede devolver datos de prueba predefinidos.

Aquí hay un ejemplo de cómo se podría implementar el doble de prueba del repositorio en Java utilizando un framework de pruebas como Mockito:

import org.example.domain.User;
import org.example.domain.UserRepository;

import java.util.ArrayList;
import java.util.List;

public class UserRepositoryMock implements UserRepository {
    private List<User> users = new ArrayList<>();

    @Override
    public void save(User user) {
        users.add(user);
    }

    @Override
    public User findById(int id) {
        return users.stream()
                .filter(user -> user.getId() == id)
                .findFirst()
                .orElse(null);
    }

    // Otros métodos del repositorio simulados...
}

En este ejemplo, UserRepositoryMock implementa la interfaz UserRepository y proporciona implementaciones simuladas de los métodos del repositorio, como save() y findById(). En lugar de interactuar con una base de datos real, simplemente almacena los usuarios en una lista en memoria.

Al utilizar este doble de prueba del repositorio en las pruebas de integración, podemos controlar el comportamiento de los métodos del repositorio y asegurarnos de que la capa de dominio funcione correctamente sin depender de la infraestructura real de acceso a datos.

Es importante destacar que los dobles de prueba se utilizan en pruebas de integración para simular componentes externos y garantizar que las diferentes capas del sistema interactúen correctamente entre sí. Estas pruebas ayudan a identificar problemas de comunicación, validación de datos y comportamiento incorrecto en la integración de componentes.

En resumen, los dobles de prueba (pruebas de integración) en las Arquitecturas Limpias permiten simular componentes externos, como repositorios, para probar la interacción y la integración correcta entre las diferentes capas del sistema sin depender de la implementación real de los componentes externos. Esto mejora la modularidad y facilita la identificación de posibles problemas de integración.

Pruebas de integración

Son pruebas que se pueden aplicar sobre la capa de aplicación donde se tienen en cuenta los siguientes componentes:

1. Sistema bajo prueba (SBP), por ejemplo el dominio.
2. Componente del que se depende (CDD), por ejemplo la base de datos y sistemas de terceros.

Problemas con el CDD

• Acceso lento.
• Control del resultado.
• Efectos colaterales.
• Disponibilidad en ambiente.
• Acceso costoso.

Doble de prueba

Es un objeto que se instala en lugar del objeto real con la intención de ejecutar la prueba, por ejemplo mocks y stubs.

Al profe se le ilumina el rostro cuando habla del efecto colateral ej. envio de correo masivo jeje, les comparto con correos hemos incluido en el subject el ambiente para identificar si es una prueba jaja lo aprendimos alarmando al mundo tambien.

Doble de firebase localmente

✅