Introducción al curso

1

Arquitectura Limpia: Diseño de Software Enfocado en el Dominio

Conceptos detrás de las Arquitecturas Limpias

2

Arquitectura Limpia: Mejorando Lógica y Dependencias

3

Características de la Arquitectura Limpia: Profundización y Ejemplos

4

Cuándo aplicar arquitecturas limpias en desarrollo de software

5

Principios SOLID: Aplicación y Ejemplos en Desarrollo de Software

Arquitecturas de referencia

6

Arquitectura Hexagonal: Puertos y Adaptadores en Sistemas de Software

7

Arquitectura Onion: Capas y Aplicaciones Prácticas

8

Desglose de la Clean Architecture por capas

9

Arquitectura Hexagonal: Caso Netflix y Startups

10

Capas de Dominio en Arquitectura Hexagonal

Dominio de una arquitectura

11

Arquitectura de Software: Buenas Prácticas en el Dominio

12

Arquitectura Java: Implementación de Script de Transacción

13

Inyección de dependencias en Java: técnicas y ejemplos prácticos

14

Modelos de Dominio en Programación Orientada a Objetos

15

Diseño de Facades en Arquitectura de Software

16

Implementación de Casos de Uso en Clean Architecture con C#

17

Implementación de CQRS en C# para Arquitecturas Limpias

Capa externa

18

Arquitectura Limpia: Acceso a Datos y Fuentes Externas

19

Patrón Repository: Separación del Dominio y Persistencia

20

Creación de APIs RESTful con Spring Boot

21

Patrones de Diseño: Implementación del Patrón Adaptador en Java

22

Pruebas Unitarias en Arquitectura Limpia: Uso de JUnit con Spring Boot

23

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

Cierre

24

Balanceo de Responsabilidades en Arquitectura Limpia

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

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

23/24
Recursos

¿Qué son las pruebas de integración y por qué son importantes?

Las pruebas de integración juegan un papel fundamental en la validación de una aplicación, ya que verifican cómo interactúan los diferentes componentes de un sistema en un entorno de aplicación real. Estas pruebas van más allá de las pruebas unitarias al considerar las dependencias y conexiones con sistemas externos, lo cual es crucial para garantizar que el sistema en su conjunto funcione correctamente.

¿Cuál es el objetivo del sistema bajo prueba (SVP)?

El sistema bajo prueba, o SVP, es el componente central que estamos evaluando para asegurarnos de que funcione correctamente. Sin embargo, para que el SVP cumpla su función, suele depender de otros componentes externos o internos, denominados componentes del cual se depende (CDD).

¿Cuáles son los desafíos de las dependencias en pruebas de integración?

Cuando realizamos pruebas de integración, enfrentamos ciertos desafíos al trabajar con las dependencias:

  • Acceso lento: Las bases de datos o sistemas externos pueden no estar disponibles localmente, afectando la rapidez de las pruebas.
  • Control del resultado: Al depender de componentes de terceros, es difícil predecir qué resultados entregarán, requiriendo a menudo una inicialización previa.
  • Efectos colaterales: Pruebas que interactúan con redes o sistemas externos pueden tener consecuencias no deseadas, como el envío de correos electrónicos indiscriminadamente.
  • Disponibilidad del componente: Algunos sistemas solo están disponibles en producción, limitando las pruebas locales.
  • Costos asociados: Acceder a ciertos servicios o API puede tener un costo económico o ser exigente en recursos.

¿Cómo superan las pruebas de integración las limitaciones?

Para abordar estos retos, se utilizan los dobles de prueba, que simulan el comportamiento de los componentes reales. Estos proporcionan un entorno controlado, donde se pueden definir los resultados esperados, eliminando muchos de los problemas asociados con las pruebas de integración.

¿Qué son los dobles de prueba?

Un doble de prueba es un sustituto del componente real que permite al desarrollador definir el comportamiento. Así, se mantiene la flexibilidad y el control durante las pruebas, en lugar de depender de un componente real.

¿Qué papel juegan los mocks y stubs?

Los mocks y stubs son tipos comunes de dobles de prueba, cada uno con funciones específicas:

  • Mocks: Simulan comportamientos en las pruebas, permitiendo verificar que un componente interactuó correctamente con sus dependencias.
  • Stubs: Proporcionan respuestas predefinidas para pruebas específicas.

Ejemplo práctico: pruebas de integración con Mockito

Mockito es un popular framework para crear mocks en pruebas de integración. Con él, las pruebas pueden establecer comportamientos específicos y verificar interacciones:

// Creación de un mock con Mockito
MyRepository mockRepository = mock(MyRepository.class);

// Configuración del comportamiento esperado
when(mockRepository.findRoute()).thenReturn(expectedRoute);

// Ejecución y verificación del comportamiento
serviceUnderTest.executeAction();
verify(mockRepository).findRoute();

Con este ejemplo se ilustra cómo los mocks permiten establecer los resultados sin acceder a la base de datos real, asegurando pruebas más rápidas y controladas.

¿Cómo afectan estas prácticas las arquitecturas limpias?

Implementar pruebas de integración con dobles de prueba, como los mocks y stubs, permite mantener arquitecturas limpias y eficaces. Así, se evidencia el beneficio de validar continuamente el funcionamiento apropiado de los sistemas en desarrollo, alineado con las mejores prácticas de prueba de software.

Al sumergirse en la rica y compleja disciplina del testing, se promueve la confianza en el software y se clarifican los caminos para optimizar aplicaciones robustas y confiables.

Aportes 8

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

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.

mockito
Debería de existir una "Ruta de Aprendizaje" más robusta en relación a este tema de pruebas, desde lo conceptual hasta los práctico, con ejemplos claros de los diferentes tipos de pruebas utilizando librerías de terceros, en diferentes lenguajes de programación, utilizando buenas prácticas, patrones, etc. Los cursos de referencia están bien, pero hace falta mucho más para complementar el aprendizaje y robustecer las habilidades de este perfil dentro de la industria del desarrollo de software.