¿Cómo probar los cambios de configuración en un servicio?

¿Cuál es el mejor enfoque para probar un servicio cuando agrega una nueva configuración? Por ejemplo, mi servicio ofrece un servicio a un cliente y, según la configuración del cliente, ofrecerá un tipo diferente de servicio. Por ejemplo, si el cliente selecciona una moneda en particular, se le ofrece un descuento del 20% en comparación con otra moneda.

El ejemplo anterior no importa. Lo que importa es el enfoque que las personas toman cuando hacen CI \ CD

La lógica para calcular el descuento está en el dominio y tiene pruebas unitarias a su alrededor. Mi pregunta es si tiene comerciantes configurados con diferentes reglas para calcular el descuento (todo basado en la configuración y el dominio lo resuelve), entonces, si llega una solicitud para cambiar la configuración, ¿cómo lo verifica?

1. ¿Escribes más pruebas?
2. ¿No pruebas como ya en las pruebas unitarias?
3. ¿Probar manualmente los cambios?
4. Otro

He leído xUnit Test Patterns y Test-Driven Development junto con muchos artículos, pero no he descubierto cómo las personas manejan esto (los cambios de configuración dentro del servicio y la verificación de la corrección).

No veo esto abordado en el libro de entrega continua tampoco.

Su lógica empresarial ya está probada por pruebas unitarias. ¿Puedes probarlo con diferentes parámetros de configuración fácilmente? Si no, debe separar esos dos:

Config <- Aplicación -> Lógica empresarial

Aquí, por ejemplo, su aplicación se encarga de leer la configuración y solo llama a la lógica de negocios con parámetros. Prueba de unidad fácil de esta manera.

En las pruebas de integración, usted prueba que todo el sistema funciona en conjunto, no la lógica de negocios.

Cree una nueva prueba de integración que tenga las condiciones requeridas y un resultado comprobable.

Una parte de la configuración de la prueba debe ser la configuración de la moneda, donde puede configurar la moneda y, por lo tanto, probar descuentos específicos.