Azure Pipelines + .NET 8: How do I run Reqnroll BDD scenarios and recorded API regression tests in the same pipeline?

Question

Azure Pipelines + .NET 8: How do I run Reqnroll BDD scenarios and recorded API regression tests in the same pipeline?

Marcus Keenton 0

I'm setting up automated testing for an ASP.NET Core 8 Web API and want to follow a BDD framework approach, with Gherkin feature files describing the business behavior. Since SpecFlow reached end of life, I've moved the scenarios to Reqnroll with xUnit.

Alongside that, I'm using Keploy to record real API traffic and generate regression tests and mocks for the same service. The idea is that the BDD scenarios cover expected behavior, while the recorded tests catch unintended changes in API responses.

Environment

.NET 8, ASP.NET Core Web API
Reqnroll 2.x + xUnit
Azure Pipelines, Microsoft-hosted ubuntu-latest agent
Tests run against the API started inside the pipeline

What I've tried

A single job running dotnet test for the Reqnroll project, then starting the API and running the recorded tests in a later step
Publishing results with PublishTestResults@2

Problem

The Reqnroll results show up in the Tests tab, but results from the second step don't appear consistently. I'm also not sure whether starting the API in the same job is the right pattern, or whether it causes port conflicts with the BDD test run.

Question

What's the recommended way to structure an Azure Pipelines YAML so both test sets run against the same API build and both publish results to the Tests tab? Should these be separate jobs or stages, and how should the API be started and stopped between them?

0 comentários

1 resposta

Sua resposta

Answer 1

Olá

Bem-vindo à Comunidade Microsoft Azure DevOps.

Boa tarde, @Marcus Keenton . Obrigado por entrar em contato conosco. Para esse cenário, eu recomendo manter um único Stage com dois Jobs, em vez de criar um Stage para cada conjunto de testes.

Job 1: inicia a mesma build da API, executa os cenários Reqnroll/xUnit e publica os resultados .trx.

Job 2: inicia novamente a mesma build da API, executa os testes de regressão do Keploy e publica os resultados no formato suportado pelo Azure Pipelines.

Use condition: always() para garantir que a API seja encerrada mesmo quando houver falha nos testes.

Cada Job pode usar sua própria porta, evitando conflitos.

Não é necessário manter a mesma instância da API entre os Jobs. O importante é que ambos utilizem a mesma build/commit.

O PublishTestResults@2 aceita formatos como TRX, JUnit, NUnit e xUnit e publica esses resultados na aba Tests do pipeline.

O ponto que eu verificaria no seu caso é o formato gerado pelo Keploy. Se ele não estiver produzindo um dos formatos aceitos, os testes podem ser executados corretamente e ainda assim não aparecerem na aba Tests. Nesse caso, será necessário converter ou adaptar a saída antes de executar PublishTestResults@2.

Exemplo da sugestão: 1 Stage → 2 Jobs → mesma build → API iniciada separadamente → resultados publicados individualmente.

Essa estrutura mantém os testes BDD e de regressão independentes, evita conflitos de processo/porta e permite identificar exatamente qual conjunto de testes apresentou falha.

Quando possível, informe também o resultado do procedimento. Seu retorno pode ajudar outros usuários que estejam enfrentando uma situação semelhante.

Nota.: Este texto foi adaptado e ccorrigido pelo Copilot de acordo com as regras do Código de Conduta e uso de IA nos fóruns Microsoft.