Megosztás a következőn keresztül:

ASP.NET Core MVC-alkalmazások tesztelése

Jótanács

Ez a tartalom egy részlet az eBookból, Architect Modern Web Applications with ASP.NET Core és Azure-ból, amely elérhető a .NET Docs-on, vagy ingyenesen letölthető PDF formájában, ami offline olvasható.

PDF letöltése

Modern webalkalmazások létrehozása a ASP.NET Core és az Azure eBook borító miniatűrjével.

"Ha nem szereti az egységtesztelést a termékén, valószínűleg az ügyfelei sem fogják szeretni a tesztelést." _- Névtelen -

Az összetett szoftverek váratlanul meghiúsulhatnak a változásokra válaszul. Ezért a módosítások elvégzése után végzett tesztelésre a legösszetűrőbb (vagy legkevésbé kritikus) alkalmazások esetében van szükség. A manuális tesztelés a szoftver tesztelésének leglassabb, legkevésbé megbízható, legdrágább módja. Sajnos, ha az alkalmazások nem tesztelésre lettek tervezve, akkor ez lehet az egyetlen elérhető tesztelési eszköz. A 4. fejezetben meghatározott architekturális alapelvek követésére írt alkalmazásoknak nagyrészt egységben tesztelhetőnek kell lenniük. ASP.NET Alapalkalmazások támogatják az automatizált integrációt és a funkcionális tesztelést.

Automatizált tesztek típusai

A szoftveralkalmazások esetében számos automatizált teszt létezik. A legegyszerűbb, legalacsonyabb szintű teszt az egységteszt. Valamivel magasabb szinten integrációs tesztek és funkcionális tesztek vannak. Más típusú tesztek, például felhasználói felületi tesztek, terheléstesztek, stressztesztek és füsttesztek nem tartoznak a dokumentum hatókörébe.

Egységtesztek

Az egységtesztek az alkalmazás logikájának egy részét tesztelik. Ezt úgy is leírhatja, hogy felsorol néhány olyan dolgot, ami nem. Az egységtesztek nem tesztelik a kód függőségekkel vagy infrastruktúrával való működését – erre szolgálnak az integrációs tesztek. Az egységteszt nem teszteli azt a keretrendszert, amelyen a kód meg van írva – feltételeznie kell, hogy működik, vagy ha azt tapasztalja, hogy mégsem, hibajelentést kell tennie, és kerülő megoldást kell alkalmaznia. Az egységtesztek teljes mértékben memóriában és folyamatban futnak. Nem kommunikál a fájlrendszerrel, a hálózattal vagy az adatbázissal. Az egységtesztek csak a kódot tesztelik.

Az egységteszteknek rendkívül gyorsan kell végrehajtaniuk, mivel csak a kód egyetlen egységét tesztelik külső függőségek nélkül. Így néhány másodperc alatt több száz egységtesztből álló tesztcsomagokat kell futtatnia. Futtassa őket gyakran, ideális esetben minden leküldés előtt egy megosztott forrásvezérlési adattárba, és természetesen a buildkiszolgálóra épülő összes automatizált buildel.

Integrációs tesztek

Bár érdemes olyan kódot beágyazni, amely olyan infrastruktúrával működik együtt, mint az adatbázisok és a fájlrendszerek, a kód egy része továbbra is elérhető lesz, és valószínűleg tesztelni szeretné azt. Emellett ellenőriznie kell, hogy a kód rétegei a várt módon működnek-e az alkalmazás függőségeinek teljes feloldásakor. Ez a funkció az integrációs tesztek feladata. Az integrációs tesztek általában lassabbak és nehezebben állíthatók be, mint az egységtesztek, mivel gyakran külső függőségtől és infrastruktúrától függenek. Ezért kerülje el az integrációs tesztekben olyan dolgok tesztelését, amelyeket egységtesztekkel lehet ellenőrizni. Ha lehetősége van egy adott forgatókönyvet egységteszttel tesztelni, akkor azt egységteszttel kell tesztelnie. Ha nem tudja, fontolja meg egy integrációs teszt használatát.

Az integrációs tesztek gyakran összetettebb beállítási és lebontási eljárásokkal rendelkeznek, mint az egységtesztek. Például egy tényleges adatbázison futó integrációs tesztnek módot kell adnia arra, hogy az adatbázist egy ismert állapotba adja vissza minden egyes teszt futtatása előtt. Az új tesztek hozzáadásával és az éles adatbázis sémájának fejlődésével ezek a tesztszkriptek mérete és összetettsége nőni fog. Sok nagy rendszerben nem célszerű teljes integrációs tesztcsomagokat futtatni a fejlesztői munkaállomásokon, mielőtt a megosztott forrásvezérlés módosításait ellenőriznénk. Ezekben az esetekben az integrációs tesztek futtathatók buildkiszolgálón.

Funkcionális tesztek

Az integrációs tesztek a fejlesztő szemszögéből vannak megírva annak ellenőrzéséhez, hogy a rendszer egyes összetevői megfelelően működnek-e együtt. A funkcionális tesztek a felhasználó szemszögéből vannak megírva, és a rendszer követelményeinek megfelelően ellenőrzik a helyességet. Az alábbi részlet hasznos hasonlatot nyújt a funkcionális tesztekre való gondolkodáshoz az egységtesztekhez képest:

"Sokszor a rendszer fejlesztése hasonlít egy ház építéséhez. Bár ez az analógia nem teljesen helyes, kiterjeszthetjük az egység és a funkcionális tesztek közötti különbség megértéséhez. Az egységtesztelés hasonló ahhoz, mint egy épületfelügyelő, aki egy ház építkezését látogatja. A ház különböző belső rendszereire, az alapozásra, a keretezésre, az elektromosságra, a vízvezetékre stb. összpontosít. Biztosítja (teszteli), hogy a ház részei megfelelően és biztonságosan működjenek, azaz megfeleljenek az építési szabályzatnak. Ebben a forgatókönyvben a funkcionális tesztek hasonlóak ahhoz, mint a háztulajdonos, aki ugyanazt az építkezést látogatja. Feltételezi, hogy a belső rendszerek megfelelően fognak viselkedni, hogy az épületfelügyelő látja el a feladatát. A háztulajdonos arra összpontosít, milyen lesz ebben a házban élni. Az érdekli őt, hogyan néz ki a ház, a különböző szobák kényelmes méretűek-e, a ház megfelel-e a család igényeinek, és jó helyen vannak-e az ablakok, hogy befogják a reggeli napsütést. A háztulajdonos funkcionális teszteket végez a házon. Ő a felhasználó szempontjából tekint a dolgokra. Az épületfelügyelő egységteszteket végez a házban. Az építő perspektíváját képviseli.

Forrás: Egységtesztelés és funkcionális tesztek

Szeretem azt mondani, hogy "Fejlesztőkként kétféleképpen hiúsulunk meg: rosszul építjük fel a dolgot, vagy rosszat építünk." Az egységtesztek biztosítják, hogy helyesen építsd fel a dolgot; funkcionális tesztek biztosítják, hogy a megfelelő dolgot építsd ki.

Mivel a funkcionális tesztek rendszerszinten működnek, bizonyos fokú felhasználói felületi automatizálásra lehet szükség. Az integrációs tesztekhez hasonlóan általában valamilyen tesztinfrastruktúrával is működnek. Ez a tevékenység lassabbá és törékenyebbé teszi őket, mint az egység- és integrációs tesztek. Csak annyi funkcionális teszttel kell rendelkeznie, amennyi biztosnak kell lennie abban, hogy a rendszer a felhasználók által elvárt módon működik.

Tesztelési piramis

Martin Fowler a tesztelési piramisról írt egy példát, amely a 9-1. ábrán látható.

Tesztelési piramis

Ábra 9-1. Tesztelési piramis

A piramis különböző rétegei és azok relatív méretei különböző teszttípusokat jelölnek, és hogy hányat kell írni az alkalmazáshoz. Mint látható, a javaslat az egységtesztek nagy bázisa, amelyet az integrációs tesztek egy kisebb rétege támogat, még kisebb funkcionális tesztréteggel. Minden rétegnek ideális esetben csak olyan tesztekkel kell rendelkeznie, amelyek alsó rétegben nem végezhetők el megfelelően. Tartsa szem előtt a tesztelési piramist, amikor megpróbálja eldönteni, hogy milyen típusú tesztre van szüksége egy adott forgatókönyvhöz.

Mit kell tesztelni?

Az automatizált tesztek írásában tapasztalatlan fejlesztők gyakran szembesülnek azzal, hogy mit teszteljenek. Jó kiindulópont a feltételes logika tesztelése. Bárhol, ahol van egy metódus, amelynek viselkedése egy feltételes állítás alapján változik (if-else, switch és hasonlók), képesnek kell lennie legalább néhány teszt megírására, amelyek megerősítik a helyes viselkedést bizonyos feltételek esetén. Ha a kód hibafeltételekkel rendelkezik, érdemes legalább egy tesztet írni a "boldog elérési út" kódon keresztül (hiba nélkül), és legalább egy tesztet a "szomorú elérési út" számára (hibákkal vagy atipikus eredményekkel), hogy az alkalmazás a várt módon viselkedjen a hibákkal szemben. Végül próbáljon meg azokra a dolgokra összpontosítani, amelyek elbukhatnak, ahelyett, hogy a metrikákra, például a kódlefedettségre összpontosítana. A kódlefedettség általában jobb, mint a kevesebb. Azonban egy összetett és üzleti szempontból kritikus módszer néhány további tesztjének írása általában jobb időt jelent, mint az automatikus tulajdonságokra vonatkozó tesztek írása, csak a tesztkód lefedettségi metrikáinak javítása érdekében.

Tesztprojektek rendszerezése

A tesztprojektek úgy rendszerezhetők, ahogy az Ön számára a legjobban működik. Érdemes a teszteket típus (egységteszt, integrációs teszt) és tesztelési (projekt, névtér szerinti) szerint elkülöníteni. Az, hogy ez az elkülönítés egyetlen tesztprojekt mappáiból vagy több tesztprojektből áll-e, tervezési döntés. Az egyik projekt a legegyszerűbb, de a sok teszttel rendelkező nagy projektek esetében, vagy a különböző tesztkészletek egyszerűbb futtatása érdekében érdemes lehet több különböző tesztprojektet futtatni. Sok csapat a tesztelési projekt alapján szervez tesztprojekteket, amelyek a több mint néhány projekttel rendelkező alkalmazások esetében nagy számú tesztprojektet eredményezhetnek, különösen akkor, ha ezeket továbbra is az egyes projektekben lévő tesztek alapján bontja le. A kompromisszumos megközelítés az, hogy egy projekt van teszttípusonként, alkalmazásonként, és a tesztprojektek mappái jelzik a tesztelt projektet (és osztályt).

Gyakori módszer az alkalmazásprojektek "src" mappában való rendszerezése, az alkalmazás tesztprojektjei pedig egy párhuzamos "tesztek" mappában. Ha hasznosnak találja ezt a szervezetet, létrehozhat egyező megoldásmappákat a Visual Studióban.

Szervezet tesztelése a megoldásban

9-2. ábra. Tesztstruktúra a megoldásban

Bármelyik tesztkörnyezetet használhatja. Az xUnit-keretrendszer jól működik, és az összes ASP.NET Core- és EF Core-teszt be van írva. xUnit tesztprojektet hozzáadhat a Visual Studióban a 9-3. ábrán látható sablonnal, vagy a parancssori felület (CLI) dotnet new xunit segítségével is.

XUnit-tesztprojekt hozzáadása a Visual Studióban

9-3. ábra. XUnit-tesztprojekt hozzáadása a Visual Studióban

Elnevezés tesztelése

Nevezze el a teszteket konzisztens módon, olyan névvel, amely jelzi az egyes tesztek elvégzését. Az egyik módszer, amellyel nagy sikert arattam, hogy a tesztosztályokat az osztály és a tesztelési módszer szerint nevezem el. Ez a megközelítés sok kis tesztosztályt eredményez, de rendkívül egyértelművé teszi, hogy az egyes tesztek miért felelősek. Ha be van állítva a tesztosztály neve, a tesztelni kívánt osztály és metódus azonosításához a tesztmetódus neve használható a tesztelt viselkedés megadásához. Ennek a névnek tartalmaznia kell a várt viselkedést, valamint azokat a bemeneteket vagy feltételezéseket, amelyek ezt a viselkedést eredményezik. Néhány példa tesztnevek:

  • CatalogControllerGetImage.CallsImageServiceWithId

  • CatalogControllerGetImage.LogsWarningGivenImageMissingException

  • CatalogControllerGetImage.ReturnsFileResultWithBytesGivenSuccess

  • CatalogControllerGetImage.ReturnsNotFoundResultGivenImageMissingException

Ennek a megközelítésnek egy változata az egyes tesztosztályok nevét "Should" kifejezéssel zárja, és kissé módosítja a feszültet:

  • CatalogControllerGetImage Kellene.HívniImageServiceWithId

  • CatalogControllerGetImage Kellene.NaplózzonWarningGivenImageMissingException

Egyes csapatok a második elnevezési megközelítést világosabban, de kissé részletesebben találják. Mindenesetre próbáljon meg olyan elnevezési konvenciót használni, amely betekintést nyújt a tesztelési viselkedésbe, így ha egy vagy több teszt meghiúsul, a nevükből nyilvánvaló, hogy mely esetek meghiúsultak. Ne nevezze el a teszteket homályosan, például a ControllerTests.Test1 nevet, mivel ezek a nevek nem adnak értéket, ha a teszteredményekben látja őket.

Ha olyan elnevezési konvenciót követ, mint a fenti, amely sok kis tesztosztályt állít elő, érdemes a teszteket mappák és névterek használatával tovább rendszerezni. A 9–4. ábra egy módszert mutat be a tesztek mappa szerinti rendszerezésére több tesztprojekten belül.

Tesztosztályok mappa szerinti rendszerezése a tesztelt osztály alapján

9-4. ábra. Tesztosztályok mappa szerinti rendszerezése a tesztelt osztály alapján.

Ha egy adott alkalmazásosztály számos tesztelt metódussal rendelkezik (és így sok tesztosztály), érdemes lehet ezeket az osztályokat az alkalmazásosztálynak megfelelő mappába helyezni. Ez a szervezet nem különbözik attól, ahogyan máshol mappákba rendezheti a fájlokat. Ha egy sok más fájlt tartalmazó mappában több mint három vagy négy kapcsolódó fájl található, gyakran hasznos lehet áthelyezni őket a saját almappájukba.

Egységtesztelés ASP.NET Core-alkalmazásokkal

Egy jól megtervezett ASP.NET Core-alkalmazásban az összetettség és az üzleti logika nagy része üzleti entitásokba és számos szolgáltatásba lesz beágyazva. A ASP.NET Core MVC-alkalmazásnak a vezérlőkkel, szűrőkkel, nézetmodellekkel és nézetekkel együtt néhány egységtesztet kell végeznie. Egy adott művelet funkcióinak nagy része a műveletmetóduson kívül esik. Annak tesztelése, hogy az útválasztás vagy a globális hibakezelés megfelelően működik-e, nem végezhető el hatékonyan egy egységteszttel. Hasonlóképpen, a szűrők, köztük a modellérvényesítési, hitelesítési és engedélyezési szűrők nem tesztelhetők egy vezérlő műveleti módszerét célzó teszttel. E viselkedési források nélkül a legtöbb műveleti módszernek triviálisan kicsinek kell lennie, és a munkájuk nagy részét olyan szolgáltatásokra kell delegálni, amelyek az őket használó vezérlőkétől függetlenül tesztelhetők.

Előfordulhat, hogy refaktorálnia kell a kódot, hogy egységtesztelhessük. Ez a tevékenység gyakran magában foglalja az absztrakciók azonosítását és a függőséginjektálás használatát a tesztelni kívánt kód absztrakciójának eléréséhez ahelyett, hogy közvetlenül az infrastruktúrán kódolást végeznénk. Vegyük például ezt az egyszerű műveletmetódust a képek megjelenítéséhez:

[HttpGet("[controller]/pic/{id}")]
public IActionResult GetImage(int id)
{
  var contentRoot = _env.ContentRootPath + "//Pics";
  var path = Path.Combine(contentRoot, id + ".png");
  Byte[] b = System.IO.File.ReadAllBytes(path);
  return File(b, "image/png");
}

A metódus egységtesztelését megnehezíti a közvetlen függése a System.IO.File-től, amelyet a fájlrendszerből való olvasáshoz használ. Ezt a viselkedést tesztelheti annak érdekében, hogy a várt módon működjön, de a valós fájlokkal való művelet integrációs teszt. Érdemes megjegyezni, hogy nem lehet egységben tesztelni ennek a módszernek az útvonalát – hamarosan látni fogja, hogyan végezheti el ezt a tesztelést egy funkcionális teszttel.

Ha nem tudja közvetlenül tesztelni a fájlrendszer viselkedését, és nem tudja tesztelni az útvonalat, mit kell tesztelni? Miután újrabontással lehetővé tette az egységtesztelést, felfedezhet néhány tesztelési esetet és hiányzó viselkedést, például hibakezelést. Mit tesz a metódus, ha nem található fájl? Mit kellene tennie? Ebben a példában az újrabontási módszer a következőképpen néz ki:

[HttpGet("[controller]/pic/{id}")]
public IActionResult GetImage(int id)
{
  byte[] imageBytes;
  try
  {
    imageBytes = _imageService.GetImageBytesById(id);
  }
  catch (CatalogImageMissingException ex)
  {
    _logger.LogWarning($"No image found for id: {id}");
    return NotFound();
  }
  return File(imageBytes, "image/png");
}

_logger és _imageService mindkettőt függőségként injektálják. Most tesztelheti, hogy ugyanazt az azonosítót adja-e át a műveletmetódusnak _imageService, és hogy az eredményül kapott bájtok a FileResult részeként lesznek visszaadva. Azt is tesztelheti, hogy a hibanaplózás a várt módon történik-e, és ha a kép hiányzik, eredmény kerül-e visszaadásra, feltéve, hogy ez a működés fontos alkalmazási viselkedés (azaz nem csak ideiglenes kód, amelyet a fejlesztő adott hozzá a probléma diagnosztizálásához). A tényleges fájllogika egy külön implementációs szolgáltatásba került, és ki lett egészítve, hogy alkalmazásspecifikus kivételt adjon vissza egy hiányzó fájl esetében. Ezt a megvalósítást önállóan is tesztelheti egy integrációs teszt használatával.

A legtöbb esetben globális kivételkezelőket kell használnia a vezérlőkben, így a bennük lévő logika minimálisnak kell lennie, és valószínűleg nem érdemes egységtesztelést végeznie. Végezze el a vezérlőműveletek tesztelésének többségét funkcionális tesztek és az TestServer alább ismertetett osztály használatával.

ASP.NET Core-alkalmazások integráció tesztelése

A ASP.NET Core-alkalmazások integrációs tesztjeinek többségének tesztelési szolgáltatásoknak és az infrastruktúra-projektben meghatározott egyéb implementációs típusoknak kell lenniük. Tesztelheti például, hogy az EF Core sikeresen frissítette és lekérte az infrastruktúraprojektben található adatelérési osztályoktól elvárt adatokat. Az ASP.NET Core MVC-projekt helyes működésének ellenőrzéséhez a legjobban olyan funkcionális tesztekkel lehet tesztelni, amelyek egy tesztgazdaszámítógépen futó alkalmazáson futnak.

Funkcionális tesztelés ASP.NET Core-alkalmazások

Az ASP.NET Core-alkalmazások esetében az osztály meglehetősen egyszerűvé teszi a TestServer funkcionális tesztek írását. Közvetlenül konfigurálhat egy TestServerWebHostBuilder-t (vagy HostBuilder-t), ahogyan azt általában az alkalmazásához teszi, vagy a WebApplicationFactory típust használhatja (a 2.1-es verzió óta elérhető). Próbálja meg a lehető legjobban igazítani a tesztrendszerét az éles rendszerhez, hogy a tesztek úgy működjenek, mint az alkalmazás éles környezetben. Az WebApplicationFactory osztály hasznos a TestServer ContentRoot konfigurálásához, amelyet a ASP.NET Core használ a statikus erőforrások, például a Nézetek megkereséséhez.

Egyszerű funkcionális teszteket úgy hozhat létre, hogy létrehoz egy olyan tesztosztályt, amely implementálja IClassFixture<WebApplicationFactory<TEntryPoint>>a TEntryPoint webalkalmazás osztályát Startup . A felület birtokában a tesztszerelvény létrehozhat egy ügyfelet a gyár CreateClient metódusával.

public class BasicWebTests : IClassFixture<WebApplicationFactory<Program>>
{
  protected readonly HttpClient _client;

  public BasicWebTests(WebApplicationFactory<Program> factory)
  {
    _client = factory.CreateClient();
  }

  // write tests that use _client
}

Jótanács

Ha minimális API-konfigurációt használ a Program.cs fájlban, alapértelmezés szerint az osztály belsőként lesz deklarálva, és nem lesz elérhető a tesztprojektből. A webes projekt bármely más példányosztályát választhatja ki, vagy hozzáadhatja a Program.cs fájlhoz:

// Make the implicit Program class public so test projects can access it
public partial class Program { }

Az egyes tesztfuttatások előtt gyakran érdemes elvégeznie a webhely néhány további konfigurációját, például konfigurálnia kell az alkalmazást egy memóriabeli adattár használatára, majd az alkalmazás tesztelési adatokkal való üzembe helyezésére. A funkció eléréséhez hozzon létre saját alosztályt WebApplicationFactory<TEntryPoint> , és bírálja felül a metódust ConfigureWebHost . Az alábbi példa az eShopOnWeb FunctionalTests projektből származik, és a fő webalkalmazás tesztjeinek részeként használatos.

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.EntityFrameworkCore;
using Microsoft.eShopWeb.Infrastructure.Data;
using Microsoft.eShopWeb.Infrastructure.Identity;
using Microsoft.eShopWeb.Web;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using System;

namespace Microsoft.eShopWeb.FunctionalTests.Web;
public class WebTestFixture : WebApplicationFactory<Startup>
{
  protected override void ConfigureWebHost(IWebHostBuilder builder)
  {
    builder.UseEnvironment("Testing");

    builder.ConfigureServices(services =>
    {
      services.AddEntityFrameworkInMemoryDatabase();

      // Create a new service provider.
      var provider = services
            .AddEntityFrameworkInMemoryDatabase()
            .BuildServiceProvider();

      // Add a database context (ApplicationDbContext) using an in-memory
      // database for testing.
      services.AddDbContext<CatalogContext>(options =>
      {
        options.UseInMemoryDatabase("InMemoryDbForTesting");
        options.UseInternalServiceProvider(provider);
      });

      services.AddDbContext<AppIdentityDbContext>(options =>
      {
        options.UseInMemoryDatabase("Identity");
        options.UseInternalServiceProvider(provider);
      });

      // Build the service provider.
      var sp = services.BuildServiceProvider();

      // Create a scope to obtain a reference to the database
      // context (ApplicationDbContext).
      using (var scope = sp.CreateScope())
      {
        var scopedServices = scope.ServiceProvider;
        var db = scopedServices.GetRequiredService<CatalogContext>();
        var loggerFactory = scopedServices.GetRequiredService<ILoggerFactory>();

        var logger = scopedServices
            .GetRequiredService<ILogger<WebTestFixture>>();

        // Ensure the database is created.
        db.Database.EnsureCreated();

        try
        {
          // Seed the database with test data.
          CatalogContextSeed.SeedAsync(db, loggerFactory).Wait();

          // seed sample user data
          var userManager = scopedServices.GetRequiredService<UserManager<ApplicationUser>>();
          var roleManager = scopedServices.GetRequiredService<RoleManager<IdentityRole>>();
          AppIdentityDbContextSeed.SeedAsync(userManager, roleManager).Wait();
        }
        catch (Exception ex)
        {
          logger.LogError(ex, $"An error occurred seeding the " +
                    "database with test messages. Error: {ex.Message}");
        }
      }
    });
  }
}

A tesztek ezt az egyéni WebApplicationFactory-t használhatják úgy, hogy létrehoznak egy ügyfelet, majd kéréseket intéznek az alkalmazáshoz ezzel az ügyfélpéldánysal. Az alkalmazás olyan adatokkal rendelkezik, amelyek a teszt állításainak részeként használhatók. Az alábbi teszt ellenőrzi, hogy az eShopOnWeb alkalmazás kezdőlapja megfelelően betöltődik-e, és tartalmaz-e egy terméklistát, amelyet a magadatok részeként adtak hozzá az alkalmazáshoz.

using Microsoft.eShopWeb.FunctionalTests.Web;
using System.Net.Http;
using System.Threading.Tasks;
using Xunit;

namespace Microsoft.eShopWeb.FunctionalTests.WebRazorPages;
[Collection("Sequential")]
public class HomePageOnGet : IClassFixture<WebTestFixture>
{
  public HomePageOnGet(WebTestFixture factory)
  {
    Client = factory.CreateClient();
  }

  public HttpClient Client { get; }

  [Fact]
  public async Task ReturnsHomePageWithProductListing()
  {
    // Arrange & Act
    var response = await Client.GetAsync("/");
    response.EnsureSuccessStatusCode();
    var stringResponse = await response.Content.ReadAsStringAsync();

    // Assert
    Assert.Contains(".NET Bot Black Sweatshirt", stringResponse);
  }
}

Ez a funkcionális teszt a teljes ASP.NET Core MVC/ Razor Pages alkalmazásvermet gyakorolja, beleértve az összes köztes szoftvert, szűrőt és kötőanyagot, amely lehetséges. Ellenőrzi, hogy egy adott útvonal ("/") a várt sikerességi állapotkódot és HTML-kimenetet adja-e vissza. Ez egy valódi webkiszolgáló beállítása nélkül teszi lehetővé, és elkerüli a valódi webkiszolgáló teszteléshez való használatával tapasztalt törékenység nagy részét (például a tűzfalbeállításokkal kapcsolatos problémákat). A TestServeren futó funkcionális tesztek általában lassabbak, mint az integrációs és egységtesztek, de sokkal gyorsabbak, mint azok a tesztek, amelyek a hálózaton futnának egy teszt webkiszolgálón. Az alkalmazás front-end technológiai stackének funkcionális teszteléssel biztosítsa, hogy az elvártak szerint működik. Ezek a tesztek különösen akkor hasznosak, ha a vezérlőkben vagy a lapokban duplikációt talál, és szűrők hozzáadásával kezeli a duplikációt. Ideális esetben ez az újrabontás nem változtatja meg az alkalmazás viselkedését, és egy funkcionális tesztcsomag ellenőrzi, hogy ez így van-e.

Hivatkozások – ASP.NET Core MVC-alkalmazások tesztelése

ElőzőKövetkező