Un problema clásico que cada desarrollador de back-end ha enfrentado durante su trabajo es probar una aplicación que utiliza una base de datos. Una solución perfectamente válida es usar la base de datos real para probar su aplicación, pero estaría haciendo una prueba de integración, mientras desea una prueba unitaria.
Hay muchas formas de resolver este problema. Puede crear la base de datos con docker, o usar una compatible en memoria, pero si está escribiendo pruebas unitarias que se pueden paralelizar fácilmente, esto será bastante incómodo. Una forma diferente de mejorar su experiencia de prueba al hacer pruebas unitarias es usar un simulacro.
¿Qué es un simulacro?
El diccionario de Cambridge define un simulacro de la siguiente manera: no es real sino que parece o finge ser exactamente como algo .
En el software, la burla se usa a menudo al escribir pruebas unitarias, ya que una API que ha escrito puede depender de otras partes complejas de su infraestructura, como una base de datos. Para aislar el comportamiento de una API, debe reemplazar los componentes externos con simulacros que simularán el comportamiento de los componentes reales.
Burlándose de Elasticsearch (y durmiendo por la noche)
El cliente que utiliza para conectarse a Elasticsearch está diseñado para que sea fácil de ampliar y adaptar a sus necesidades. Gracias a su arquitectura interna, le permite cambiar algunos componentes específicos mientras mantiene el resto funcionando como de costumbre. Cada cliente oficial de Elasticsearch está compuesto por los siguientes componentes:
La mejor manera de burlarse de Elasticsearch con los clientes oficiales es reemplazar el componente Connection, ya que tiene muy pocas responsabilidades y no interactúa con otros componentes internos que no sean recibir solicitudes y devolver respuestas.
Fuente e informe completo: Blog Elastic
Linware Argentina ⯈