Testes de integração no ASP.NET Core

Por Jos van der Til, Martin Costelloe Javier Calvarro Nelson.

Os testes de integração garantem que os componentes de um aplicativo funcionem corretamente em um nível que inclua a infraestrutura de suporte do aplicativo, como o banco de dados, o sistema de arquivos e a rede. O ASP.NET Core suporta testes de integração usando uma estrutura de teste de unidade com um host de teste e um servidor de teste na memória.

Este artigo pressupõe uma compreensão básica de testes de unidade. Se não estiver familiarizado com conceitos de teste, consulte o artigo Teste de Unidade no .NET Core e no .NET Standard e seu conteúdo associado.

Visualizar ou baixar código de exemplo (como transferir)

A aplicação de exemplo é uma aplicação Razor Páginas e pressupõe um conhecimento básico de Razor Páginas. Se não estiver familiarizado com o Razor Pages, consulte os seguintes artigos:

• Introdução ao Razor Pages
• Comece com Razor Pages
• Razor testes de unidade do Pages

Para testar SPAs, recomendamos uma ferramenta como Playwright for .NET, que pode automatizar um navegador.

Introdução aos testes de integração

Os testes de integração avaliam os componentes de um aplicativo em um nível mais amplo do que testes de unidade. Os testes de unidade são usados para testar componentes de software isolados, como métodos de classe individuais. Os testes de integração confirmam que dois ou mais componentes do aplicativo trabalham juntos para produzir um resultado esperado, possivelmente incluindo todos os componentes necessários para processar totalmente uma solicitação.

Esses testes mais amplos são usados para testar a infraestrutura e toda a estrutura do aplicativo, geralmente incluindo os seguintes componentes:

• Base de dados
• Sistema de ficheiros
• Dispositivos de rede
• Pipeline de solicitação-resposta

Os testes de unidade usam componentes fabricados, conhecidos como falsos ou objetos falsificados, no lugar de componentes de infraestrutura.

Em contraste com os testes de unidade, os testes de integração:

• Use os componentes reais que o aplicativo usa na produção.
• Exigem mais código e processamento de dados.
• Leve mais tempo para correr.

Portanto, limite o uso de testes de integração aos cenários de infraestrutura mais importantes. Se um comportamento puder ser testado usando um teste de unidade ou um teste de integração, escolha o teste de unidade.

Em discussões de testes de integração, o projeto testado é frequentemente chamado de System Under Test, ou "SUT" para abreviar. "SUT" é usado ao longo deste artigo para se referir ao aplicativo ASP.NET Core que está sendo testado.

Não escreva testes de integração para cada de permutação de dados e acesso a arquivos com bancos de dados e sistemas de arquivos. Independentemente de quantos lugares em um aplicativo interagem com bancos de dados e sistemas de arquivos, um conjunto focado de testes de integração de leitura, gravação, atualização e exclusão geralmente é capaz de testar adequadamente os componentes do banco de dados e do sistema de arquivos. Use testes de unidade para testes de rotina de lógica de método que interagem com esses componentes. Em testes de unidade, o uso de falsificações ou simulações de infraestrutura resulta em execução de teste mais rápida.

ASP.NET Testes de integração principais

Os testes de integração no ASP.NET Core requerem o seguinte:

• Um projeto de teste é usado para conter e executar os testes. O projeto de teste tem uma referência ao SUT.
• O projeto de teste cria um host de teste para o SUT e usa um cliente de servidor de teste para lidar com solicitações e respostas com o SUT.
• Um corredor de teste é usado para executar os testes e relatar os resultados do teste.

Os testes de integração seguem uma sequência de eventos que incluem as etapas usuais de teste Preparar, Agire Asserir:

1. A hospedagem web da SUT está configurada.
2. Um cliente de servidor de teste é criado para enviar solicitações ao aplicativo.
3. A etapa de teste Organizar é executada: o aplicativo de teste prepara uma solicitação.
4. A etapa de teste do Act é executada: o cliente envia a solicitação e recebe a resposta.
5. A etapa de teste Assert é executada: A resposta real é validada como uma de aprovação ou falha com base em uma resposta esperada.
6. O processo continua até que todos os testes sejam executados.
7. Os resultados dos testes são divulgados.

Normalmente, o host da Web de teste é configurado de forma diferente do host normal do aplicativo para as execuções de teste. Por exemplo, um banco de dados diferente ou configurações de aplicativo diferentes podem ser usados para os testes.

Os componentes de infraestrutura, como o host da Web de teste e o servidor de teste na memória (TestServer), são fornecidos ou gerenciados pelo pacote Microsoft.AspNetCore.Mvc.Testing. O uso deste pacote simplifica a criação e execução de testes.

O pacote Microsoft.AspNetCore.Mvc.Testing lida com as seguintes tarefas:

• Copia o arquivo de dependências (.deps) do SUT para o diretório bin do projeto de teste.
• Define a raiz de conteúdo como a raiz do projeto do SUT para que arquivos estáticos e páginas/visualizações sejam encontrados quando os testes forem executados.
• Fornece a classe WebApplicationFactory, para simplificar o processo de configuração do SUT com TestServer.

A documentação de testes de unidade descreve como configurar um projeto de teste e uma ferramenta de execução de testes, juntamente com instruções detalhadas sobre como executar testes e recomendações sobre como nomear testes e classes de teste.

Separe os testes de unidade dos testes de integração em diferentes projetos. Separar os testes:

• Ajuda a garantir que os componentes de teste de infraestrutura não sejam incluídos acidentalmente nos testes de unidade.
• Permite controlar qual conjunto de testes é executado.

Não há praticamente nenhuma diferença entre a configuração para testes de aplicativos do Razor Pages e aplicativos MVC. A única diferença está na forma como os testes são nomeados. Em uma aplicação Razor Pages, os testes de pontos de extremidade de página geralmente são baseados no nome da classe do modelo de página (por exemplo, IndexPageTests para testar a integração de componentes na página Índice). Em um aplicativo MVC, os testes geralmente são organizados por classes de controlador e nomeados após os controladores que eles testam (por exemplo, HomeControllerTests para testar a integração de componentes para o controlador Home).

Pré-requisitos do aplicativo de teste

O projeto de ensaio deve:

• Faça referência ao pacote Microsoft.AspNetCore.Mvc.Testing.
• Especifique o SDK da Web no arquivo de projeto (<Project Sdk="Microsoft.NET.Sdk.Web">).

Esses pré-requisitos podem ser vistos no aplicativo de exemplo . Inspecione o arquivo tests/RazorPagesProject.Tests/RazorPagesProject.Tests.csproj. A aplicação de exemplo usa a estrutura de teste xUnit e a biblioteca do analisador AngleSharp, portanto, a aplicação de exemplo também faz referência:

• AngleSharp
• xunit
• xunit.runner.visualstudio

Em aplicativos que usam xunit.runner.visualstudio versão 2.4.2 ou posterior, o projeto de teste deve fazer referência ao pacote Microsoft.NET.Test.Sdk.

O Entity Framework Core também é usado nos testes. Consulte o arquivo de projeto no GitHub.

Ambiente SUT

Se o ambiente do do SUT não estiver definido, o ambiente padrão será Desenvolvimento.

Testes básicos com o padrão WebApplicationFactory

Exponha a classe Program implicitamente definida para o projeto de teste seguindo um destes procedimentos:

• Exponha tipos internos do aplicativo Web para o projeto de teste. Isso pode ser feito no arquivo do projeto SUT (.csproj):

  <ItemGroup>
       <InternalsVisibleTo Include="MyTestProject" />
  </ItemGroup>
  

• Torne a classe Program pública usando uma declaração parcial de classe:

  var builder = WebApplication.CreateBuilder(args);
  // ... Configure services, routes, etc.
  app.Run();
  + public partial class Program { }
  

  A aplicação de exemplo usa a abordagem de classe parcial Program.

WebApplicationFactory<TEntryPoint> é usado para criar um TestServer para os testes de integração. TEntryPoint é a classe de ponto de entrada do SUT, geralmente Program.cs.

As classes de teste implementam uma interface de fixação de classe (IClassFixture) para indicar que a classe contém testes e fornecer instâncias de objetos partilhados entre os testes na classe.

A seguinte classe de teste, BasicTests, usa o WebApplicationFactory para inicializar o SUT e providenciar um HttpClient a um método de teste, Get_EndpointsReturnSuccessAndCorrectContentType. O método verifica se o código de status da resposta foi bem-sucedido (200-299) e o cabeçalho Content-Type está text/html; charset=utf-8 para várias páginas do aplicativo.

CreateClient() cria uma instância de HttpClient que segue automaticamente redirecionamentos e lida com cookies.

public class BasicTests 
    : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly WebApplicationFactory<Program> _factory;

    public BasicTests(WebApplicationFactory<Program> factory)
    {
        _factory = factory;
    }

    [Theory]
    [InlineData("/")]
    [InlineData("/Index")]
    [InlineData("/About")]
    [InlineData("/Privacy")]
    [InlineData("/Contact")]
    public async Task Get_EndpointsReturnSuccessAndCorrectContentType(string url)
    {
        // Arrange
        var client = _factory.CreateClient();

        // Act
        var response = await client.GetAsync(url);

        // Assert
        response.EnsureSuccessStatusCode(); // Status Code 200-299
        Assert.Equal("text/html; charset=utf-8", 
            response.Content.Headers.ContentType.ToString());
    }
}

Por padrão, os cookies não essenciais não são preservados nas solicitações quando a política de consentimento do Regulamento Geral de Proteção de Dados está ativada. Para preservar cookies não essenciais, como os usados pelo provedor TempData, marque-os como essenciais em seus testes. Para obter instruções sobre como marcar um cookie como essencial, consulte Cookies essenciais.

AngleSharp vs Application Parts para verificações antifalsificação

Este artigo usa o analisador AngleSharp para lidar com as verificações antifalsificação carregando páginas e analisando o HTML. Para testar os pontos de extremidade das visualizações do controlador e do Razor Pages em um nível inferior, sem se preocupar com a forma como eles são renderizados no navegador, considere usar Application Parts. A abordagem Application Parts injeta um controlador ou Razor Page no aplicativo que pode ser usado para fazer solicitações JSON para obter os valores necessários. Para obter mais informações, consulte o blog Integration Testing ASP.NET Core Resources Protected with Antiforgery Using Application Parts e de repositório GitHub associado pelo Martin Costello.

Personalizar WebApplicationFactory

É possível criar a configuração do host da Web de forma independente das classes de teste, por meio da herança de WebApplicationFactory<TEntryPoint> para criar uma ou mais fábricas personalizadas.

1. Herdar de WebApplicationFactory e substituir ConfigureWebHost. O IWebHostBuilder permite a configuração da coleção de serviços com IWebHostBuilder.ConfigureServices

   public class CustomWebApplicationFactory<TProgram>
       : WebApplicationFactory<TProgram> where TProgram : class
   {
       protected override void ConfigureWebHost(IWebHostBuilder builder)
       {
           builder.ConfigureServices(services =>
           {
               var dbContextDescriptor = services.SingleOrDefault(
                   d => d.ServiceType == 
                       typeof(IDbContextOptionsConfiguration<ApplicationDbContext>));
   
               services.Remove(dbContextDescriptor);
   
               var dbConnectionDescriptor = services.SingleOrDefault(
                   d => d.ServiceType ==
                       typeof(DbConnection));
   
               services.Remove(dbConnectionDescriptor);
   
               // Create open SqliteConnection so EF won't automatically close it.
               services.AddSingleton<DbConnection>(container =>
               {
                   var connection = new SqliteConnection("DataSource=:memory:");
                   connection.Open();
   
                   return connection;
               });
   
               services.AddDbContext<ApplicationDbContext>((container, options) =>
               {
                   var connection = container.GetRequiredService<DbConnection>();
                   options.UseSqlite(connection);
               });
           });
   
           builder.UseEnvironment("Development");
       }
   }
   

   A propagação do banco de dados no aplicativo de exemplo é executada pelo método InitializeDbForTests. O método é descrito no exemplo de testes de integração na seção : Organização da aplicação de teste.

   O contexto da base de dados da SUT está registado em Program.cs. O retorno de chamada builder.ConfigureServices do aplicativo de teste é executado depois de o código Program.cs do aplicativo é executado. Para usar um banco de dados diferente nos testes em vez do banco de dados do aplicativo, o contexto do banco de dados do aplicativo deve ser substituído em builder.ConfigureServices.

   O aplicativo de exemplo localiza o descritor de serviço para o contexto do banco de dados e usa o descritor para remover o registro de serviço. Em seguida, a fábrica adiciona um novo ApplicationDbContext que usa um banco de dados na memória para os testes.

   Para se conectar a um banco de dados diferente, altere o DbConnection. Para usar um banco de dados de teste do SQL Server:

   • Faça referência ao pacote NuGet Microsoft.EntityFrameworkCore.SqlServer no arquivo de projeto.
   • Ligue para UseInMemoryDatabase.

2. Utilize o CustomWebApplicationFactory personalizado em classes de teste. O exemplo a seguir usa a fábrica na classe IndexPageTests:

   public class IndexPageTests :
       IClassFixture<CustomWebApplicationFactory<Program>>
   {
       private readonly HttpClient _client;
       private readonly CustomWebApplicationFactory<Program>
           _factory;
   
       public IndexPageTests(
           CustomWebApplicationFactory<Program> factory)
       {
           _factory = factory;
           _client = factory.CreateClient(new WebApplicationFactoryClientOptions
           {
               AllowAutoRedirect = false
           });
       }
   

   O cliente do aplicativo de exemplo está configurado para impedir que o HttpClient siga redirecionamentos. Conforme explicado mais adiante na seção de autenticação simulada, isso permite que os testes verifiquem o resultado da primeira resposta do aplicativo. A primeira resposta é um redirecionamento em muitos desses testes com um cabeçalho Location.

3. Um teste típico usa os métodos HttpClient e auxiliar para processar a solicitação e a resposta:

   [Fact]
   public async Task Post_DeleteAllMessagesHandler_ReturnsRedirectToRoot()
   {
       // Arrange
       var defaultPage = await _client.GetAsync("/");
       var content = await HtmlHelpers.GetDocumentAsync(defaultPage);
   
       //Act
       var response = await _client.SendAsync(
           (IHtmlFormElement)content.QuerySelector("form[id='messages']"),
           (IHtmlButtonElement)content.QuerySelector("button[id='deleteAllBtn']"));
   
       // Assert
       Assert.Equal(HttpStatusCode.OK, defaultPage.StatusCode);
       Assert.Equal(HttpStatusCode.Redirect, response.StatusCode);
       Assert.Equal("/", response.Headers.Location.OriginalString);
   }
   

Qualquer solicitação POST ao SUT deve passar pela verificação de antifalsificação feita automaticamente pelo sistema de proteção de dados contra falsificação do aplicativo. Para organizar a solicitação POST de um teste, o aplicativo de teste deve:

1. Faça um pedido para a página.
2. Analise o cookie antifalsificação e solicite o token de validação da resposta.
3. Faça a solicitação POST com o antifalsificação cookie e solicite o token de validação em vigor.

Os métodos de extensão auxiliar SendAsync (Helpers/HttpClientExtensions.cs) e o método auxiliar GetDocumentAsync (Helpers/HtmlHelpers.cs) na aplicação de exemplo usam o analisador AngleSharp para manipular a verificação antifalsificação com os seguintes métodos:

• GetDocumentAsync: Recebe o HttpResponseMessage e devolve um IHtmlDocument. GetDocumentAsync usa uma fábrica que prepara uma resposta virtual com base no HttpResponseMessageoriginal. Para obter mais informações, consulte a documentação do AngleSharp.
• SendAsync métodos de extensão para o HttpClient compõem um HttpRequestMessage e chamam SendAsync(HttpRequestMessage) para enviar solicitações ao SUT. Sobrecargas para SendAsync aceitam o formulário HTML (IHtmlFormElement) e o seguinte:
  • Botão Enviar do formulário (IHtmlElement)
  • Coleção de valores de formulário (IEnumerable<KeyValuePair<string, string>>)
  • Botão Enviar (IHtmlElement) e valores de formulário (IEnumerable<KeyValuePair<string, string>>)

AngleSharp é uma biblioteca de análises sintáticas de terceiros usada para fins de demonstração neste artigo e na aplicação de exemplo. O AngleSharp não é suportado ou necessário para testes de integração de aplicativos ASP.NET Core. Outros analisadores podem ser usados, como o Html Agility Pack (HAP). Outra abordagem é escrever código para lidar com o token de verificação de solicitação do sistema antifalsificação e o antifalsificação cookie diretamente. Consulte AngleSharp vs Application Parts para verificações antifalsificação neste artigo para obter mais informações.

O EF-Core provedor de banco de dados na memória pode ser usado para testes limitados e básicos, no entanto, o provedor SQLite é a escolha recomendada para testes na memória.

Consulte Estender a Inicialização com Filtros de Inicialização, que mostra como configurar middleware usando IStartupFilter, o que é útil quando um teste requer um serviço ou middleware personalizado.

Personalize o cliente com WithWebHostBuilder

Quando uma configuração adicional é necessária dentro de um método de teste, WithWebHostBuilder cria um novo WebApplicationFactory com um IWebHostBuilder que é ainda mais personalizado pela configuração.

O código de exemplo chama WithWebHostBuilder para substituir serviços configurados por stubs de teste. Para obter mais informações e exemplos de uso, consulte de serviços simulados de injeção neste artigo.

O método de teste Post_DeleteMessageHandler_ReturnsRedirectToRoot do aplicativo de exemplo demonstra o uso de WithWebHostBuilder. Este teste executa uma exclusão de registro no banco de dados acionando um envio de formulário no SUT.

Como outro teste na classe IndexPageTests executa uma operação que exclui todos os registros no banco de dados e pode ser executado antes do método Post_DeleteMessageHandler_ReturnsRedirectToRoot, o banco de dados é repropagado nesse método de teste para garantir que um registro esteja presente para o SUT excluir. A seleção do primeiro botão de exclusão do formulário messages no SUT é simulada na solicitação ao SUT:

[Fact]
public async Task Post_DeleteMessageHandler_ReturnsRedirectToRoot()
{
    // Arrange
    using (var scope = _factory.Services.CreateScope())
    {
        var scopedServices = scope.ServiceProvider;
        var db = scopedServices.GetRequiredService<ApplicationDbContext>();

        Utilities.ReinitializeDbForTests(db);
    }

    var defaultPage = await _client.GetAsync("/");
    var content = await HtmlHelpers.GetDocumentAsync(defaultPage);

    //Act
    var response = await _client.SendAsync(
        (IHtmlFormElement)content.QuerySelector("form[id='messages']"),
        (IHtmlButtonElement)content.QuerySelector("form[id='messages']")
            .QuerySelector("div[class='panel-body']")
            .QuerySelector("button"));

    // Assert
    Assert.Equal(HttpStatusCode.OK, defaultPage.StatusCode);
    Assert.Equal(HttpStatusCode.Redirect, response.StatusCode);
    Assert.Equal("/", response.Headers.Location.OriginalString);
}

Opções do cliente

Consulte a página WebApplicationFactoryClientOptions para obter os padrões e as opções disponíveis ao criar instâncias HttpClient.

Crie a classe WebApplicationFactoryClientOptions e passe-a para o método CreateClient():

public class IndexPageTests :
    IClassFixture<CustomWebApplicationFactory<Program>>
{
    private readonly HttpClient _client;
    private readonly CustomWebApplicationFactory<Program>
        _factory;

    public IndexPageTests(
        CustomWebApplicationFactory<Program> factory)
    {
        _factory = factory;
        _client = factory.CreateClient(new WebApplicationFactoryClientOptions
        {
            AllowAutoRedirect = false
        });
    }

NOTA: Para evitar avisos de redirecionamento HTTPS em logs ao usar o middleware de redirecionamento HTTPS, defina BaseAddress = new Uri("https://localhost")

Injetar serviços simulados

Os serviços podem ser substituídos em um teste com uma chamada para ConfigureTestServices no construtor de hosts. Para definir o escopo dos serviços substituídos para o teste em si, o método WithWebHostBuilder é usado para recuperar um host builder. Isso pode ser visto nos seguintes testes:

• Get_QuoteService_ProvidesQuoteInPage
• Obter_PáginaDePerfilGithubPodeObterUmUtilizadorGithub
• A_PáginaSeguraÉRetornadaParaUmUtilizadorAutenticado

O SUT de exemplo inclui um serviço com um escopo definido que retorna uma citação. A cotação é incorporada em um campo oculto na página Índice quando a página Índice é solicitada.

Services/IQuoteService.cs:

public interface IQuoteService
{
    Task<string> GenerateQuote();
}

Services/QuoteService.cs:

// Quote ©1975 BBC: The Doctor (Tom Baker); Dr. Who: Planet of Evil
// https://www.bbc.co.uk/programmes/p00pyrx6
public class QuoteService : IQuoteService
{
    public Task<string> GenerateQuote()
    {
        return Task.FromResult<string>(
            "Come on, Sarah. We've an appointment in London, " +
            "and we're already 30,000 years late.");
    }
}

Program.cs:

services.AddScoped<IQuoteService, QuoteService>();

Pages/Index.cshtml.cs:

public class IndexModel : PageModel
{
    private readonly ApplicationDbContext _db;
    private readonly IQuoteService _quoteService;

    public IndexModel(ApplicationDbContext db, IQuoteService quoteService)
    {
        _db = db;
        _quoteService = quoteService;
    }

    [BindProperty]
    public Message Message { get; set; }

    public IList<Message> Messages { get; private set; }

    [TempData]
    public string MessageAnalysisResult { get; set; }

    public string Quote { get; private set; }

    public async Task OnGetAsync()
    {
        Messages = await _db.GetMessagesAsync();

        Quote = await _quoteService.GenerateQuote();
    }

Pages/Index.cs:

<input id="quote" type="hidden" value="@Model.Quote">

A seguinte marcação é gerada quando o aplicativo SUT é executado:

<input id="quote" type="hidden" value="Come on, Sarah. We&#x27;ve an appointment in 
    London, and we&#x27;re already 30,000 years late.">

Para testar o serviço e a injeção de cotação em um teste de integração, um serviço simulado é injetado no SUT pelo teste. O serviço simulado substitui o QuoteService do aplicativo por um serviço fornecido pelo aplicativo de teste, chamado TestQuoteService:

IntegrationTests.IndexPageTests.cs:

// Quote ©1975 BBC: The Doctor (Tom Baker); Pyramids of Mars
// https://www.bbc.co.uk/programmes/p00pys55
public class TestQuoteService : IQuoteService
{
    public Task<string> GenerateQuote()
    {
        return Task.FromResult(
            "Something's interfering with time, Mr. Scarman, " +
            "and time is my business.");
    }
}

Quando o ConfigureTestServices é chamado, o serviço com escopo é registado.

[Fact]
public async Task Get_QuoteService_ProvidesQuoteInPage()
{
    // Arrange
    var client = _factory.WithWebHostBuilder(builder =>
        {
            builder.ConfigureTestServices(services =>
            {
                services.AddScoped<IQuoteService, TestQuoteService>();
            });
        })
        .CreateClient();

    //Act
    var defaultPage = await client.GetAsync("/");
    var content = await HtmlHelpers.GetDocumentAsync(defaultPage);
    var quoteElement = content.QuerySelector("#quote");

    // Assert
    Assert.Equal("Something's interfering with time, Mr. Scarman, " +
        "and time is my business.", quoteElement.Attributes["value"].Value);
}

A marcação gerada durante a execução do teste reflete o texto da citação citado por TestQuoteService, portanto, a asserção é bem-sucedida.

<input id="quote" type="hidden" value="Something&#x27;s interfering with time, 
    Mr. Scarman, and time is my business.">

Autenticação simulada

Os testes na classe AuthTests verificam se um endpoint seguro:

• Redireciona um usuário não autenticado para a página de login do aplicativo.
• Retorna conteúdo para um usuário autenticado.

No SUT, a página /SecurePage utiliza uma convenção denominada AuthorizePage para aplicar um elemento AuthorizeFilter à página. Para obter mais informações, consulte as convenções de autorização das páginas Razor.

services.AddRazorPages(options =>
{
    options.Conventions.AuthorizePage("/SecurePage");
});

No teste de Get_SecurePageRedirectsAnUnauthenticatedUser, um WebApplicationFactoryClientOptions é definido para não permitir redirecionamentos definindo AllowAutoRedirect como false:

[Fact]
public async Task Get_SecurePageRedirectsAnUnauthenticatedUser()
{
    // Arrange
    var client = _factory.CreateClient(
        new WebApplicationFactoryClientOptions
        {
            AllowAutoRedirect = false
        });

    // Act
    var response = await client.GetAsync("/SecurePage");

    // Assert
    Assert.Equal(HttpStatusCode.Redirect, response.StatusCode);
    Assert.StartsWith("http://localhost/Identity/Account/Login",
        response.Headers.Location.OriginalString);
}

Ao não permitir que o cliente siga o redirecionamento, as seguintes verificações podem ser feitas:

• O código de status retornado pelo SUT pode ser verificado em relação ao resultado HttpStatusCode.Redirect esperado, não o código de status final após o redirecionamento para a página de login, que seria HttpStatusCode.OK.
• O valor do cabeçalho Location nos cabeçalhos de resposta é verificado para confirmar que começa com http://localhost/Identity/Account/Login, e não com a resposta final da página de início de sessão, onde o cabeçalho Location não estaria presente.

O aplicativo de teste pode simular um AuthenticationHandler<TOptions> em ConfigureTestServices para testar aspetos de autenticação e autorização. Um cenário mínimo retorna AuthenticateResult.Success:

public class TestAuthHandler : AuthenticationHandler<AuthenticationSchemeOptions>
{
    public TestAuthHandler(IOptionsMonitor<AuthenticationSchemeOptions> options,
        ILoggerFactory logger, UrlEncoder encoder)
        : base(options, logger, encoder)
    {
    }

    protected override Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        var claims = new[] { new Claim(ClaimTypes.Name, "Test user") };
        var identity = new ClaimsIdentity(claims, "Test");
        var principal = new ClaimsPrincipal(identity);
        var ticket = new AuthenticationTicket(principal, "TestScheme");

        var result = AuthenticateResult.Success(ticket);

        return Task.FromResult(result);
    }
}

O TestAuthHandler é chamado para autenticar um usuário quando o esquema de autenticação é definido como TestScheme onde AddAuthentication está registrado para ConfigureTestServices. É importante que o esquema de TestScheme corresponda ao esquema esperado pelo seu aplicativo. Caso contrário, a autenticação não funcionará.

[Fact]
public async Task Get_SecurePageIsReturnedForAnAuthenticatedUser()
{
    // Arrange
    var client = _factory.WithWebHostBuilder(builder =>
        {
            builder.ConfigureTestServices(services =>
            {
                services.AddAuthentication(defaultScheme: "TestScheme")
                    .AddScheme<AuthenticationSchemeOptions, TestAuthHandler>(
                        "TestScheme", options => { });
            });
        })
        .CreateClient(new WebApplicationFactoryClientOptions
        {
            AllowAutoRedirect = false,
        });

    client.DefaultRequestHeaders.Authorization =
        new AuthenticationHeaderValue(scheme: "TestScheme");

    //Act
    var response = await client.GetAsync("/SecurePage");

    // Assert
    Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}

Para obter mais informações sobre WebApplicationFactoryClientOptions, consulte a seção opções do cliente.

Testes básicos para middleware de autenticação

Consulte este repositório no GitHub para testes básicos de middleware de autenticação. Ele contém um servidor de teste que é específico para o cenário de teste.

Definir o ambiente

Defina o ambiente na fábrica de aplicações personalizadas:

public class CustomWebApplicationFactory<TProgram>
    : WebApplicationFactory<TProgram> where TProgram : class
{
    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureServices(services =>
        {
            var dbContextDescriptor = services.SingleOrDefault(
                d => d.ServiceType == 
                    typeof(IDbContextOptionsConfiguration<ApplicationDbContext>));

            services.Remove(dbContextDescriptor);

            var dbConnectionDescriptor = services.SingleOrDefault(
                d => d.ServiceType ==
                    typeof(DbConnection));

            services.Remove(dbConnectionDescriptor);

            // Create open SqliteConnection so EF won't automatically close it.
            services.AddSingleton<DbConnection>(container =>
            {
                var connection = new SqliteConnection("DataSource=:memory:");
                connection.Open();

                return connection;
            });

            services.AddDbContext<ApplicationDbContext>((container, options) =>
            {
                var connection = container.GetRequiredService<DbConnection>();
                options.UseSqlite(connection);
            });
        });

        builder.UseEnvironment("Development");
    }
}

Como a infraestrutura de teste infere o caminho raiz do conteúdo do aplicativo

O construtor WebApplicationFactory infere o caminho da raiz de conteúdo da aplicação procurando um WebApplicationFactoryContentRootAttribute no assembly que contém os testes de integração com uma chave igual ao assembly TEntryPointSystem.Reflection.Assembly.FullName. Caso um atributo com a chave correta não seja encontrado, WebApplicationFactory volta a procurar por um arquivo de solução (.sln) e acrescenta o nome do assembly TEntryPoint ao diretório da solução. O diretório raiz do aplicativo (o caminho da raiz do conteúdo) é usado para descobrir exibições e arquivos de conteúdo.

Desativar cópia de sombra

A cópia de sombra faz com que os testes sejam executados em um diretório diferente do diretório de saída. Se os testes dependerem do carregamento de arquivos relativos ao Assembly.Location e você encontrar problemas, talvez seja necessário desabilitar a cópia de sombra.

Para desativar a cópia de sombras ao usar xUnit, crie um arquivo de xunit.runner.json no diretório do projeto de teste, com a configuração correta .

{
  "shadowCopy": false
}

Eliminação de objetos

Depois que os testes da implementação do IClassFixture são executados, TestServer e HttpClient são descartados quando xUnit descarta o WebApplicationFactory. Se os objetos instanciados pelo desenvolvedor precisarem ser eliminados, elimine-os na implementação IClassFixture. Para obter mais informações, consulte Implementing a Dispose method.

Exemplo de testes de integração

O de aplicativo de exemplo é composto por dois aplicativos:

Aplicação	Diretório de projetos	Descrição
Aplicativo de mensagem (o SUT)	src/RazorPagesProject	Permite que um usuário adicione, exclua um, exclua todos e analise mensagens.
Aplicativo de teste	tests/RazorPagesProject.Tests	Usado para testar a integração do SUT.

Os testes podem ser executados usando os recursos de teste internos de um IDE, como Visual Studio. Se estiver usando Visual Studio Code ou a linha de comando, execute o seguinte comando em um prompt de comando no diretório tests/RazorPagesProject.Tests:

dotnet test

Organização do aplicativo de mensagem (SUT)

O SUT é um sistema de mensagens Razor Pages com as seguintes características:

• A página Índice do aplicativo (Pages/Index.cshtml e Pages/Index.cshtml.cs) fornece uma interface do usuário e métodos de modelo de página para controlar a adição, exclusão e análise de mensagens (média de palavras por mensagem).
• Uma mensagem é descrita pela classe Message (Data/Message.cs) com duas propriedades: Id (chave) e Text (mensagem). A propriedade Text é obrigatória e limitada a 200 caracteres.
• As mensagens são armazenadas usando o banco de dados na memória do Entity Framework †.
• O aplicativo contém uma camada de acesso a dados (DAL) em sua classe de contexto de banco de dados, AppDbContext (Data/AppDbContext.cs).
• Se o banco de dados estiver vazio na inicialização do aplicativo, o armazenamento de mensagens será inicializado com três mensagens.
• O aplicativo inclui um /SecurePage que só pode ser acessado por um usuário autenticado.

†O artigo do EF, Test with InMemory, explica como usar um banco de dados na memória para testes com o MSTest. Este tópico usa o xUnit estrutura de teste. Os conceitos de teste e as implementações de teste em diferentes estruturas de teste são semelhantes, mas não idênticos.

Embora o aplicativo não use o padrão de repositório e não seja um exemplo eficaz do padrão de Unidade de Trabalho (UoW), o Razor Pages oferece suporte a esses padrões de desenvolvimento. Para mais informações, consulte Conceção da camada de persistência da infraestrutura e Lógica do controlador de testes (o exemplo implementa o padrão de repositório).

Testar a organização do aplicativo

O aplicativo de teste é um aplicativo de console dentro do diretório tests/RazorPagesProject.Tests.

Diretório de aplicativos de teste	Descrição
AuthTests	Contém métodos de teste para: Aceder a uma página segura por um utilizador não autenticado. Aceder a uma página segura por um utilizador autenticado com uma simulação AuthenticationHandler<TOptions>. Obter um perfil de usuário do GitHub e verificar o login de usuário do perfil.
BasicTests	Contém um método de teste para roteamento e tipo de conteúdo.
IntegrationTests	Contém os testes de integração para a página Índice usando a classe WebApplicationFactory personalizada.
Helpers/Utilities	Utilities.cs contém o método InitializeDbForTests usado para semear o banco de dados com dados de teste. O HtmlHelpers.cs fornece um método para retornar um AngleSharp IHtmlDocument para uso nos métodos de teste. HttpClientExtensions.cs fornece sobrecargas para SendAsync enviar solicitações ao SUT.

A estrutura de teste é xUnit. Os testes de integração são realizados usando o Microsoft.AspNetCore.TestHost, que inclui o TestServer. Como o pacote Microsoft.AspNetCore.Mvc.Testing é usado para configurar o host de teste e o servidor de teste, os pacotes TestHost e TestServer não exigem referências diretas de pacote no arquivo de projeto do aplicativo de teste ou na configuração do desenvolvedor no aplicativo de teste.

Os testes de integração geralmente exigem um pequeno conjunto de dados no banco de dados antes da execução do teste. Por exemplo, um teste de exclusão chama para uma exclusão de registro de banco de dados, portanto, o banco de dados deve ter pelo menos um registro para que a solicitação de exclusão seja bem-sucedida.

O aplicativo de exemplo semeia o banco de dados com três mensagens em Utilities.cs que os testes podem usar quando são executados:

public static void InitializeDbForTests(ApplicationDbContext db)
{
    db.Messages.AddRange(GetSeedingMessages());
    db.SaveChanges();
}

public static void ReinitializeDbForTests(ApplicationDbContext db)
{
    db.Messages.RemoveRange(db.Messages);
    InitializeDbForTests(db);
}

public static List<Message> GetSeedingMessages()
{
    return new List<Message>()
    {
        new Message(){ Text = "TEST RECORD: You're standing on my scarf." },
        new Message(){ Text = "TEST RECORD: Would you like a jelly baby?" },
        new Message(){ Text = "TEST RECORD: To the rational mind, " +
            "nothing is inexplicable; only unexplained." }
    };
}

O contexto da base de dados da SUT está registado em Program.cs. O retorno de chamada builder.ConfigureServices do aplicativo de teste é executado depois de o código Program.cs do aplicativo é executado. Para usar um banco de dados diferente para os testes, o contexto do banco de dados do aplicativo deve ser substituído em builder.ConfigureServices. Para mais informações, consulte a seção Personalizar WebApplicationFactory .

Recursos adicionais

• Testes unitários
• Testes unitários do Razor Pages no ASP.NET Core
• ASP.NET Core Middleware
• Lógica do controlador de teste no ASP.NET Core
• Testes básicos para middleware de autenticação