Como você testa que dois serviços ainda funcionam juntos sem subir o sistema inteiro?

Use teste de contrato. O consumidor define as requisições que faz e o formato de resposta de que depende, essa expectativa é publicada como um contrato, e o provedor a verifica dentro do próprio pipeline. Os dois lados então testam de forma independente e rápida, e uma mudança quebradora falha o build do provedor em vez de aparecer num ambiente compartilhado dias depois.

Ambientes end to end completos não escalam além de um punhado de serviços. São lentos, precisam que o build mais recente de todo time esteja saudável ao mesmo tempo, e quando algo fica vermelho a primeira pergunta é sempre se é um defeito real ou o ambiente. Teste de contrato contorna isso. O consumidor escreve testes contra um stub local do provedor, e essas interações são gravadas como um contrato: para esta requisição, eu dependo destes campos com estes tipos. Esse contrato é publicado, e o pipeline do próprio provedor o reproduz contra a implementação real do provedor. Se alguém renomeia um campo ou muda um tipo, o build deles falha, no repositório deles, minutos depois da mudança, com uma mensagem nomeando qual consumidor quebra. Esse é o valor inteiro: o feedback aterrissa onde a mudança foi feita. A nuance que vale enunciar é que um contrato só cobre o que o consumidor de fato usa, não a superfície completa do provedor, então ele não substitui os testes funcionais do provedor, e verifica compatibilidade e não correção de negócio. Eu ainda mantenho uma suíte end to end pequena para as poucas jornadas que realmente precisam ser provadas entre serviços.