Testy integracji w programie ASP.NET Core

Przez Jos van der Til, Martin Costello i Javier Calvarro Nelson.

Testy integracji zapewniają prawidłowe działanie składników aplikacji na poziomie obejmującym infrastrukturę pomocniczą aplikacji, taką jak baza danych, system plików i sieć. ASP.NET Core obsługuje testy integracji przy użyciu struktury testów jednostkowych z testowym hostem internetowym i serwerem testowym w pamięci.

W tym artykule zakłada się podstawową znajomość testów jednostkowych. Jeśli nie masz pewności co do pojęć związanych z testowaniem, zobacz artykuł Unit Testing in .NET Core and .NET Standard (Testowanie jednostkowe na platformie .NET Core i .NET Standard ) oraz jego połączoną zawartość.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Przykładowa aplikacja to Razor Pages app i wymaga podstawowej znajomości Razor Pages. Jeśli nie znasz Razor Pages, zobacz następujące artykuły:

• Wprowadzenie do Razor stron
• Rozpocznij pracę z Razor Pages
• Razor Testy jednostkowe stron

Do testowania spAs zalecamy narzędzie, takie jak Playwright dla platformy .NET, które może zautomatyzować przeglądarkę.

Wprowadzenie do testów integracji

Testy integracji oceniają składniki aplikacji na szerszym poziomie niż testy jednostkowe. Testy jednostkowe służą do testowania izolowanych składników oprogramowania, takich jak poszczególne metody klasy. Testy integracji potwierdzają, że co najmniej dwa składniki aplikacji współpracują ze sobą, aby wygenerować oczekiwany wynik, prawdopodobnie włącznie z każdym składnikiem wymaganym do pełnego przetworzenia żądania.

Te szersze testy służą do testowania infrastruktury aplikacji i całej struktury, często w tym następujących składników:

• baza danych
• System plików
• Urządzenia sieciowe
• Przepływ żądań i odpowiedzi

Testy jednostkowe używają sfabrykowanych składników, znanych jako fałszywe lub makiety obiektów, zamiast składników infrastruktury.

W przeciwieństwie do testów jednostkowych, testy integracji:

• Użyj rzeczywistych składników używanych przez aplikację w środowisku produkcyjnym.
• Wymagaj więcej kodu i przetwarzania danych.
• Uruchamianie trwa dłużej.

W związku z tym ogranicz użycie testów integracji do najważniejszych scenariuszy infrastruktury. Jeśli zachowanie można przetestować przy użyciu testu jednostkowego lub testu integracji, wybierz test jednostkowy.

W dyskusjach na temat testów integracyjnych testowany projekt jest często nazywany Systemem Pod Testami, lub w skrócie "SUT". Element "SUT" jest używany w tym artykule do odwoływania się do testowanej aplikacji ASP.NET Core.

Nie zapisuj testów integracji dla każdej permutacji danych i dostępu do plików za pomocą baz danych i systemów plików. Niezależnie od liczby miejsc w aplikacji współdziała z bazami danych i systemami plików, skoncentrowany zestaw testów integracji odczytu, zapisu, aktualizacji i usuwania zwykle umożliwia odpowiednie testowanie składników bazy danych i systemu plików. Używaj testów jednostkowych do rutynowych testów logiki metod, które wchodzą w interakcje z tymi składnikami. W testach jednostkowych użycie fałszywych elementów infrastruktury lub imitacji przyspiesza wykonywanie testów.

testy integracji ASP.NET Core

Testy integracji w programie ASP.NET Core wymagają następujących elementów:

• Projekt testowy służy do zawierania i wykonywania testów. Projekt testowy zawiera odwołanie do sutu.
• Projekt testowy tworzy serwer testowy dla SUT i korzysta z klienta serwera testowego do obsługi żądań i odpowiedzi z SUT.
• Moduł uruchamiający testy służy do wykonywania testów i zgłaszania wyników testu.

Testy integracji są zgodne z sekwencją zdarzeń obejmującą zwykłe kroki testowe: Rozmieszczenie, Działanie i Sprawdzenie.

1. Host internetowy SUT jest skonfigurowany.
2. Klient serwera testowego jest tworzony w celu przesyłania żądań do aplikacji.
3. Etap Aranżacji testu jest realizowany: aplikacja testowa przygotowuje żądanie.
4. Krok testu aktu jest wykonywany: klient przesyła żądanie i odbiera odpowiedź.
5. Krok testu potwierdzenia jest wykonywany: rzeczywista odpowiedź jest weryfikowana jako powodzenie lub niepowodzenie w oparciu o oczekiwaną odpowiedź.
6. Proces będzie kontynuowany do momentu wykonania wszystkich testów.
7. Wyniki testów są zgłaszane.

Zazwyczaj testowy host internetowy jest skonfigurowany inaczej niż normalny host internetowy aplikacji na potrzeby przebiegów testu. Na przykład do testów mogą być używane różne ustawienia bazy danych lub różnych aplikacji.

Składniki infrastruktury, takie jak testowy host internetowy i serwer testowy w pamięci (TestServer), są dostarczane lub zarządzane przez pakiet Microsoft.AspNetCore.Mvc.Testing . Użycie tego pakietu usprawnia tworzenie i wykonywanie testów.

Pakiet Microsoft.AspNetCore.Mvc.Testing obsługuje następujące zadania:

• Kopiuje plik zależności (.deps) z sutu do katalogu projektu testowego bin .
• Ustawia katalog główny zawartości na katalog główny projektu SUT, tak aby pliki statyczne i strony/widoki zostały znalezione podczas wykonywania testów.
• Udostępnia klasę WebApplicationFactory , aby usprawnić uruchamianie aplikacji SUT za pomocą polecenia TestServer.

W dokumentacji testów jednostkowych opisano sposób konfigurowania projektu testowego i modułu uruchamiającego testy oraz szczegółowe instrukcje dotyczące uruchamiania testów i zaleceń dotyczących sposobu nazywania testów i klas testowych.

Oddziel testy jednostkowe od testów integracji do różnych projektów. Oddzielanie testów:

• Pomaga zagwarantować, że składniki testowania infrastruktury nie zostaną przypadkowo uwzględnione w testach jednostkowych.
• Umożliwia kontrolę nad tym, który zestaw testów jest uruchamiany.

Praktycznie nie ma różnicy między konfiguracją testów Razor aplikacji Pages i aplikacji MVC. Jedyną różnicą jest sposób, w jaki testy są nazwane. Razor W aplikacji Pages testy punktów końcowych strony są zwykle nazwane po klasie modelu strony (na przykład IndexPageTests w celu przetestowania integracji składników dla strony Indeks). W aplikacji MVC testy są zwykle zorganizowane według klas kontrolerów i nazwane po testowych kontrolerach (na przykład HomeControllerTests do testowania integracji składników dla Home kontrolera).

Testowanie wymagań wstępnych aplikacji

Projekt testowy musi:

• Odwołaj się do pakietu Microsoft.AspNetCore.Mvc.Testing.
• Określ zestaw Web SDK w pliku projektu (<Project Sdk="Microsoft.NET.Sdk.Web">).

Te wymagania wstępne można zobaczyć w przykładowej aplikacji. tests/RazorPagesProject.Tests/RazorPagesProject.Tests.csproj Sprawdź plik. Przykładowa aplikacja używa struktury testowej xUnit i biblioteki analizatora AngleSharp , więc przykładowa aplikacja również odwołuje się do:

• AngleSharp
• xunit
• xunit.runner.visualstudio

W aplikacjach korzystających z wersji 2.4.2 lub nowszej xunit.runner.visualstudio, projekt testowy musi odwoływać się do pakietu Microsoft.NET.Test.Sdk.

Program Entity Framework Core jest również używany w testach. Zobacz plik projektu w usłudze GitHub.

Środowisko SUT

Jeśli środowisko SUT nie jest ustawione, środowisko jest domyślnie ustawione na Programowanie.

Podstawowe testy z domyślną funkcją WebApplicationFactory

Uwidaczniaj niejawnie zdefiniowaną Program klasę w projekcie testowym, wykonując jedną z następujących czynności:

• Uwidacznij typy wewnętrzne z aplikacji internetowej dla projektu testowego. Można to zrobić w pliku projektu SUT (.csproj):

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

• Ustaw klasę Program jako publiczną przy użyciu deklaracji klasy częściowej:

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

  Przykładowa aplikacja używa Program metody klasy częściowej.

WebApplicationFactory<TEntryPoint> służy do tworzenia elementu TestServer dla testów integracji. TEntryPoint jest klasą punktu wejścia systemu SUT, zwykle Program.cs.

Klasy testowe implementują interfejs fixture klasy (IClassFixture), aby wskazać, że klasa zawiera testy i udostępnia wspólne wystąpienia obiektów między testami w klasie.

Następująca klasa testowa BasicTests używa WebApplicationFactory do uruchomienia SUT i dostarczenia HttpClient do metody testowej Get_EndpointsReturnSuccessAndCorrectContentType. Metoda sprawdza, czy kod stanu odpowiedzi jest pomyślny (200–299), a nagłówek ma wartość text/html; charset=utf-8 na kilku stronach aplikacji.

CreateClient() Program tworzy wystąpienie HttpClient , które automatycznie śledzi przekierowania i obsługuje pliki cookie.

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());
    }
}

Domyślnie pliki cookie inne niż podstawowe nie są zachowywane w żądaniach, gdy zasady zgody ogólnego rozporządzenia o ochronie danych są włączone. Aby zachować nieistotne pliki cookie, takie jak te używane przez dostawcę TempData, oznacz je jako niezbędne w testach. Aby uzyskać instrukcje dotyczące oznaczania cookie elementu jako niezbędnego, zobacz Podstawowe pliki cookie.

AngleSharp vs Application Parts kontra antyfałszerstwo

W tym artykule użyto analizatora AngleSharp do obsługi testów antyforgeryjnych przez ładowanie stron i analizowanie kodu HTML. Aby przetestować punkty końcowe kontrolera i widoki stron Razor na niższym poziomie, bez martwienia się o sposób renderowania w przeglądarce, rozważ użycie Application Parts. Metoda Części aplikacji wprowadza kontroler lub Razor stronę do aplikacji, która może służyć do tworzenia żądań JSON w celu uzyskania wymaganych wartości. Aby uzyskać więcej informacji, zobacz blog Testowanie integracji zasobów ASP.NET Core chronionych przed fałszerstwami przy użyciu części aplikacji oraz powiązane repozytorium GitHub autorstwa Martina Costello.

Dostosować WebApplicationFactory

Konfigurację hosta internetowego można utworzyć niezależnie od klas testowych, dziedzicząc z WebApplicationFactory<TEntryPoint> w celu utworzenia co najmniej jednej fabryki niestandardowej:

1. Dziedzicz z WebApplicationFactory i przesłaniaj ConfigureWebHost. Element IWebHostBuilder umożliwia konfigurację kolekcji usług za pomocą polecenia 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");
       }
   }
   

   Rozmieszczanie bazy danych w przykładowej aplikacji jest wykonywane przez metodę InitializeDbForTests . Metoda została opisana w sekcji Przykładowe testy integracji: Testowanie organizacji aplikacji.

   Kontekst bazy danych SUT jest zarejestrowany w pliku Program.cs. Wywołanie zwrotne aplikacji builder.ConfigureServices testowej jest wykonywane po wykonaniu kodu aplikacji Program.cs . Aby użyć innej bazy danych do testów niż baza danych aplikacji, kontekst bazy danych aplikacji musi zostać zastąpiony w pliku builder.ConfigureServices.

   Przykładowa aplikacja znajduje deskryptor usługi dla kontekstu bazy danych i używa deskryptora do usunięcia rejestracji usługi. Następnie fabryka dodaje nowy ApplicationDbContext , który używa bazy danych w pamięci do testów.

   Aby nawiązać połączenie z inną bazą danych, zmień wartość DbConnection. Aby użyć testowej bazy danych programu SQL Server:

   • Dodaj odwołanie do pakietu NuGet w pliku projektu.
   • Zadzwoń UseInMemoryDatabase.

2. Użyj niestandardowego CustomWebApplicationFactory w klasach testowych. W poniższym przykładzie użyto fabryki w klasie 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
           });
       }
   

   Klient przykładowej aplikacji jest skonfigurowany tak, aby zapobiec HttpClient następującym przekierowaniom. Jak wyjaśniono w sekcji Mock uwierzytelnianie, pozwala to testom na sprawdzenie wyniku pierwszej odpowiedzi aplikacji. Pierwsza odpowiedź to przekierowanie w wielu z tych testów z nagłówkiem Location .

3. Typowy test używa HttpClient oraz metod pomocniczych do przetwarzania żądania i odpowiedzi.

   [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);
   }
   

Każde żądanie POST do SUT musi spełniać kontrolę antyforgeryjną, która jest automatycznie dokonana przez system ochrony danych aplikacji. Aby zorganizować żądanie POST testu, aplikacja testowa musi:

1. Utwórz żądanie dla strony.
2. Przeanalizuj token antyforgery i cookie żądaj weryfikacji z odpowiedzi.
3. Utwórz żądanie POST z tokenem antyforgery i cookie zażądaj weryfikacji.

SendAsync Pomocnicze metody rozszerzenia (Helpers/HttpClientExtensions.cs) i metoda pomocnika (Helpers/HtmlHelpers.cs) w przykładowej aplikacji używają analizatora AngleSharp do obsługi sprawdzania pod kątem ochrony przed fałszerstwami za pomocą następujących metod:

• GetDocumentAsync: Odbiera element HttpResponseMessage i zwraca wartość IHtmlDocument. GetDocumentAsync używa mechanizmu, który przygotowuje wirtualną odpowiedź na podstawie oryginalnego HttpResponseMessage. Aby uzyskać więcej informacji, zobacz dokumentację AngleSharp.
• SendAsync metody rozszerzenia dla HttpClient tworzą HttpRequestMessage i wywołują SendAsync(HttpRequestMessage) w celu przesłania żądań do SUT. Przeciążenia dla SendAsync akceptują formularz HTML (IHtmlFormElement) i następujące elementy:
  • Przycisk Prześlij formularza (IHtmlElement)
  • Kolekcja wartości formularza (IEnumerable<KeyValuePair<string, string>>)
  • Przycisk Prześlij (IHtmlElement) i wartości formularza (IEnumerable<KeyValuePair<string, string>>)

AngleSharp to biblioteka do analizy od strony trzeciej używana do celów demonstracyjnych w tym artykule i przykładowej aplikacji. Funkcja AngleSharp nie jest obsługiwana ani wymagana do testowania integracji aplikacji ASP.NET Core. Można użyć innych analizatorów, takich jak Pakiet Zwinności HTML (HAP). Innym podejściem jest napisanie kodu do obsługi tokenu weryfikacji żądania systemu ochrony przed fałszerstwem oraz bezpośredniego zarządzania systemem antyfałszerstwowym cookie. Aby uzyskać więcej informacji, zobacz AngleSharp kontra Application Parts do weryfikacji antyfałszerstw w tym artykule.

Dostawca bazy danych EF-Core w pamięci może służyć do ograniczonego i podstawowego testowania, jednak dostawca SQLite jest zalecanym wyborem do testowania w pamięci.

Zobacz Rozszerzanie uruchamiania za pomocą filtrów uruchamiania, które pokazuje, jak skonfigurować oprogramowanie pośredniczące przy użyciu IStartupFilter, co jest przydatne, gdy test wymaga niestandardowej usługi lub oprogramowania pośredniczącego.

Dostosowywanie klienta za pomocą programu WithWebHostBuilder

Jeśli w metodzie testowej wymagana jest dodatkowa konfiguracja, WithWebHostBuilder tworzy nowy WebApplicationFactory, zawierający IWebHostBuilder, który został dalej skonfigurowany zgodnie z potrzebami.

Przykładowy kod wywołuje WithWebHostBuilder aby zastąpić skonfigurowane usługi próbkami testowymi. Aby uzyskać więcej informacji i przykłady użycia, zapoznaj się z sekcją Wstrzykiwanie usług mock w tym artykule.

Metoda Post_DeleteMessageHandler_ReturnsRedirectToRoot testowa przykładowej aplikacji demonstruje użycie metody WithWebHostBuilder. Ten test wykonuje usunięcie rekordu w bazie danych, wyzwalając przesłanie formularza w SUT.

Ponieważ inny test w IndexPageTests klasie wykonuje operację, która usuwa wszystkie rekordy w bazie danych i może zostać uruchomiona przed Post_DeleteMessageHandler_ReturnsRedirectToRoot metodą, baza danych jest ponownie zainicjowana w tej metodzie testowej, aby upewnić się, że rekord jest obecny, aby SUT mógł usunąć. Wybranie pierwszego przycisku usuwania w formularzu messages w SUT jest symulowane w żądaniu do 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);
}

Opcje klienta

Zobacz stronę WebApplicationFactoryClientOptions dotyczącą ustawień domyślnych i dostępnych opcji podczas tworzenia instancji HttpClient.

Utwórz klasę WebApplicationFactoryClientOptions i przekaż ją do CreateClient() metody :

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
        });
    }

UWAGA: Aby uniknąć ostrzeżeń przekierowania HTTPS w dziennikach podczas korzystania z oprogramowania pośredniczącego przekierowania HTTPS, ustaw BaseAddress = new Uri("https://localhost")

Wstrzykiwanie makiety usług

Usługi można zastąpić w teście za pomocą wywołania metody ConfigureTestServices w konstruktorze hosta. Aby ograniczyć zakres nadpisanych usług do samego testu, metoda WithWebHostBuilder jest używana w celu uzyskania konstruktora hosta. Można to zobaczyć w następujących testach:

• Get_QuoteService_ProvidesQuoteInPage
• Get_GithubProfilePageCanGetAGithubUser
• Pobierz_ZabezpieczonąStronęDlaUwierzytelnionegoUżytkownika

Przykładowy SUT zawiera usługę o zdefiniowanym zakresie, która zwraca cytat. Cytat jest osadzony w ukrytym polu na stronie indeks, gdy żądana jest strona indeks.

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">

Po uruchomieniu aplikacji SUT jest generowany następujący kod:

<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.">

Aby przetestować usługę i przeprowadzić iniekcję w teście integracji, usługa symulowana jest wstrzykiwana do systemu testowanego przez test. Usługa pozorowania zastępuje aplikację QuoteService usługą dostarczaną przez aplikację testową o nazwie 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.");
    }
}

ConfigureTestServices zostaje wywołana, a usługa o określonym zakresie zostaje zarejestrowana:

[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);
}

Znacznik wygenerowany podczas wykonywania testu odzwierciedla tekst cudzysłowu dostarczony przez element TestQuoteService, w związku z czym asercja przechodzi.

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

Symulacja uwierzytelniania

Testy w AuthTests klasie sprawdzają, czy bezpieczny punkt końcowy:

• Przekierowuje nieuwierzytelnionego użytkownika do strony logowania aplikacji.
• Zwraca zawartość dla uwierzytelnionego użytkownika.

Na stronie SUT /SecurePage jest używana AuthorizePage konwencja stosowania elementu AuthorizeFilter do strony. Aby uzyskać więcej informacji, zobacz Razor Konwencje autoryzacji stron.

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

W teście Get_SecurePageRedirectsAnUnauthenticatedUser wartość WebApplicationFactoryClientOptions jest ustawiona tak, aby nie zezwalała na przekierowania, ustawiając parametr AllowAutoRedirect na 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);
}

Nie zezwalając klientowi na obserwowanie przekierowania, można wykonać następujące kontrole:

• Kod stanu zwrócony przez SUT można sprawdzić względem oczekiwanego HttpStatusCode.Redirect wyniku, a nie końcowego kodu stanu po przekierowaniu do strony logowania, który byłby HttpStatusCode.OK.
• Wartość nagłówka Location w nagłówkach odpowiedzi jest sprawdzana, aby potwierdzić, że rozpoczyna się od http://localhost/Identity/Account/Login, a nie od odpowiedzi końcowej strony logowania, gdzie nagłówek Location nie byłby obecny.

Aplikacja testowa może symulować AuthenticationHandler<TOptions> w ConfigureTestServices w celu przetestowania aspektów uwierzytelniania i autoryzacji. Minimalny scenariusz zwraca wartość :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);
    }
}

Element TestAuthHandler jest wywoływany w celu uwierzytelnienia użytkownika, gdy ustawiono schemat uwierzytelniania jako TestScheme, gdzie AddAuthentication jest zarejestrowany dla ConfigureTestServices. Ważne jest, TestScheme aby schemat był zgodny ze schematem oczekiwanym przez aplikację. W przeciwnym razie uwierzytelnianie nie będzie działać.

[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);
}

Aby uzyskać więcej informacji na temat WebApplicationFactoryClientOptions, zobacz sekcję Opcje klienta.

Podstawowe testy oprogramowania pośredniczącego uwierzytelniania

Zobacz to repozytorium GitHub, aby zapoznać się z podstawowymi testami oprogramowania pośredniczącego uwierzytelniania. Zawiera on serwer testowy specyficzny dla scenariusza testowego.

Ustawianie środowiska

Ustaw środowisko w niestandardowej fabryce aplikacji:

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");
    }
}

Jak infrastruktura testowa wywnioskuje ścieżkę główną zawartości aplikacji

Konstruktor WebApplicationFactory ustala ścieżkę katalogu głównego zawartości aplikacji poprzez wyszukiwanie elementu WebApplicationFactoryContentRootAttribute w zestawie, który zawiera testy integracyjne, z kluczem równym zestawowi TEntryPointSystem.Reflection.Assembly.FullName. Jeśli atrybut z poprawnym kluczem nie zostanie znaleziony, WebApplicationFactory wraca do wyszukiwania pliku rozwiązania (.sln) i dodaje TEntryPoint nazwę zestawu do katalogu rozwiązania. Katalog główny aplikacji (ścieżka główna zawartości) służy do odnajdywania widoków i plików zawartości.

Wyłącz kopiowanie w tle

Kopiowanie w tle powoduje wykonanie testów w innym katalogu niż katalog wyjściowy. Jeśli testy polegają na ładowaniu plików względem Assembly.Location i napotkasz problemy, może być konieczne wyłączenie kopiowania w tle.

Aby wyłączyć kopiowanie cieni przy użyciu xUnit, utwórz plik xunit.runner.json w katalogu projektu testowego z poprawnym ustawieniem konfiguracji:

{
  "shadowCopy": false
}

Usuwanie obiektów

Po przeprowadzeniu testów implementacji IClassFixture, TestServer i HttpClient są usuwane, gdy xUnit usuwa WebApplicationFactory. Jeśli obiekty utworzone przez dewelopera wymagają usunięcia, należy je usunąć w implementacji IClassFixture . Aby uzyskać więcej informacji, zobacz Metoda Dispose — implementacja.

Przykład testów integracji

Przykładowa aplikacja składa się z dwóch aplikacji:

Aplikacja	Katalog projektu	opis
Aplikacja komunikatów (SUT)	src/RazorPagesProject	Umożliwia użytkownikowi dodawanie, usuwanie jednego, usuwanie wszystkich i analizowanie komunikatów.
Testowanie aplikacji	tests/RazorPagesProject.Tests	Służy do testowania integracji systemu (SUT).

Testy można uruchamiać przy użyciu wbudowanych funkcji testowych środowiska IDE, takich jak Visual Studio. Jeśli używasz programu Visual Studio Code lub wiersza polecenia, wykonaj następujące polecenie w wierszu polecenia w tests/RazorPagesProject.Tests katalogu:

dotnet test

Organizacja aplikacji wiadomości (SUT)

SUT to Razor system komunikatów Pages o następujących cechach:

• Strona Indeks aplikacji (Pages/Index.cshtml i Pages/Index.cshtml.cs) udostępnia metody interfejsu użytkownika i modelu strony do kontrolowania dodawania, usuwania i analizowania komunikatów (średnie słowa na komunikat).
• Komunikat jest opisany przez klasę Message (Data/Message.cs) z dwiema właściwościami: Id (klucz) i Text (komunikat). Właściwość Text jest wymagana i ograniczona do 200 znaków.
• Komunikaty są przechowywane przy użyciu bazy danych w pamięci programu Entity Framework†.
• Aplikacja zawiera warstwę dostępu do danych (DAL) w swojej klasie AppDbContext kontekstu bazy danych (Data/AppDbContext.cs).
• Jeśli baza danych jest pusta podczas uruchamiania aplikacji, magazyn komunikatów jest inicjowany z trzema komunikatami.
• Aplikacja zawiera element /SecurePage , do którego można uzyskać dostęp tylko przez uwierzytelnionego użytkownika.

† Artykuł EF, Test z InMemory, wyjaśnia, jak używać bazy danych w pamięci do testów przy użyciu narzędzia MSTest. W tym temacie jest używana struktura testowa xUnit . Koncepcje testów i implementacje testów w różnych platformach testowych są podobne, ale nie identyczne.

Mimo że aplikacja nie używa wzorca repozytorium i nie jest skutecznym przykładem Unit of Work (UoW), Razor Pages obsługuje te wzorce rozwoju. Aby uzyskać więcej informacji zobaczysz Projektowanie warstwy trwałości infrastruktury i Testowanie logiki kontrolera (przykład implementuje wzorzec repozytorium).

Testowanie organizacji aplikacji

Aplikacja testowa jest aplikacją konsolową wewnątrz tests/RazorPagesProject.Tests katalogu.

Testowanie katalogu aplikacji	opis
AuthTests	Zawiera metody testowe dla: Uzyskiwanie dostępu do bezpiecznej strony przez nieuwierzytelnionego użytkownika. Uzyskiwanie dostępu do bezpiecznej strony przez uwierzytelnionego użytkownika z użyciem pozornego elementu AuthenticationHandler<TOptions>. Uzyskiwanie profilu użytkownika usługi GitHub i sprawdzanie logowania użytkownika profilu.
BasicTests	Zawiera metodę testową routingu i typu zawartości.
IntegrationTests	Zawiera testy integracji dla strony Indeks przy użyciu klasy niestandardowej WebApplicationFactory .
Helpers/Utilities	Utilities.cs zawiera metodę InitializeDbForTests, używaną do zasiewania bazy danych danymi testowymi. HtmlHelpers.cs Udostępnia metodę zwracania obiektu AngleSharp IHtmlDocument do użytku przez metody testowe. HttpClientExtensions.cs zapewnij przeciążenia dla SendAsync aby przesyłać żądania do SUT.

Struktura testowa to xUnit. Testy integracji są przeprowadzane przy użyciu Microsoft.AspNetCore.TestHost, który zawiera TestServer. Ponieważ pakiet Microsoft.AspNetCore.Mvc.Testing jest używany do konfigurowania hosta testowego i serwera testowego, pakiety TestHost i TestServer nie wymagają bezpośrednich odwołań w pliku projektu aplikacji testowej ani ręcznej konfiguracji przez dewelopera w tej aplikacji.

Testy integracji zwykle wymagają małego zestawu danych w bazie danych przed wykonaniem testu. Na przykład test usuwania wywołuje usunięcie rekordu bazy danych, więc baza danych musi mieć co najmniej jeden rekord, aby żądanie usunięcia powiodło się.

Przykładowa aplikacja zapełnia bazę danych trzema komunikatami w Utilities.cs, które mogą być używane przez testy podczas ich wykonywania:

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." }
    };
}

Kontekst bazy danych SUT jest zarejestrowany w pliku Program.cs. Wywołanie zwrotne aplikacji builder.ConfigureServices testowej jest wykonywane po wykonaniu kodu aplikacji Program.cs . Aby użyć innej bazy danych do testów, kontekst bazy danych aplikacji musi zostać zastąpiony w pliku builder.ConfigureServices. Aby uzyskać więcej informacji, zobacz sekcję Customize WebApplicationFactory.

Dodatkowe zasoby

• Testy jednostkowe
• Testy jednostkowe stron Razor na platformie ASP.NET Core
• oprogramowanie pośredniczące ASP.NET Core
• Logika kontrolera testów w ASP.NET Core
• Podstawowe testy oprogramowania pośredniczącego uwierzytelniania