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

Az ASP.NET Core-szolgáltatások és -webalkalmazások tesztelése

Tipp.

Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.

PDF letöltése

.NET mikroszolgáltatások architektúrája konténerizált .NET alkalmazásokhoz e-könyv borító miniatűr.

A vezérlők minden ASP.NET Core API-szolgáltatás és ASP.NET MVC-webalkalmazás központi részét képezik. Ezért biztosnak kell lennie abban, hogy az alkalmazásnak megfelelően viselkednek. Az automatizált tesztek ezt a megbízhatóságot biztosítják, és észlelhetik a hibákat, mielőtt éles környezetbe érnének.

Tesztelnie kell, hogy a vezérlő hogyan viselkedik érvényes vagy érvénytelen bemenetek alapján, és tesztelnie kell a vezérlő válaszait az általa végrehajtott üzleti művelet eredménye alapján. A mikroszolgáltatásokhoz azonban az alábbi típusú teszteket kell elvégeznie:

  • Egységtesztek. Ezek a tesztek biztosítják, hogy az alkalmazás egyes összetevői a várt módon működjenek. Az állítások tesztelik a komponens API-t.

  • Integrációs tesztek. Ezek a tesztek biztosítják, hogy az összetevők interakciói a várt módon működjenek külső összetevőkkel, például adatbázisokkal szemben. Az állítások tesztelhetik az összetevő API-ját, felhasználói felületét vagy az olyan műveletek mellékhatásait, mint az adatbázis I/O-ja, a naplózás stb.

  • Funkcionális tesztek az egyes mikroszolgáltatásokhoz. Ezek a tesztek biztosítják, hogy az alkalmazás a felhasználó szempontjából a várt módon működjön.

  • Szolgáltatástesztek. Ezek a tesztek biztosítják a végpontok közötti szolgáltatáshasználati eseteket, beleértve több szolgáltatás egyidejű tesztelését is. Az ilyen típusú teszteléshez először a környezetet kell előkészíteni. Ebben az esetben ez azt jelenti, hogy elindítja a szolgáltatásokat (például docker-compose up használatával).

Egységtesztek implementálása ASP.NET Core Webes API-khoz

Az egységtesztelés magában foglalja az alkalmazás egy részének tesztelését az infrastruktúrától és a függőségektől elkülönítve. A tesztvezérlő logikájának egyesével csak egy művelet vagy metódus tartalmát teszteli, nem pedig a függőségek vagy a keretrendszer viselkedését. Az egységtesztek nem észlelik az összetevők közötti interakcióval kapcsolatos problémákat – ez az integrációs tesztelés célja.

A vezérlőműveletek egységtesztelése során győződjön meg arról, hogy csak azok viselkedésére összpontosít. A vezérlőegység-teszt elkerüli a szűrőket, az útválasztást vagy a modellkötést (a kérelemadatok leképezését Egy ViewModel-hez vagy DTO-hoz). Mivel csak egy dolog tesztelésére összpontosítanak, az egységtesztek általában egyszerűen írhatók és gyorsan futtathatók. Az egységtesztek jól megírt készlete gyakran, nagy terhelés nélkül futtatható.

Az egységtesztek olyan tesztelési keretrendszereken alapulnak, mint xUnit.net, MSTest, Moq vagy NUnit. Az eShopOnContainers mintaalkalmazáshoz xUnitot használunk.

Amikor egy web API-vezérlő egységtesztet ír, a vezérlőosztályt közvetlenül a C# új kulcsszójának használatával példányosíthatja, hogy a teszt a lehető leggyorsabban fusson. Az alábbi példa bemutatja, hogyan teheti ezt meg az xUnit tesztelési keretrendszerként való használatakor.

[Fact]
public async Task Get_order_detail_success()
{
    //Arrange
    var fakeOrderId = "12";
    var fakeOrder = GetFakeOrder();

    //...

    //Act
    var orderController = new OrderController(
        _orderServiceMock.Object,
        _basketServiceMock.Object,
        _identityParserMock.Object);

    orderController.ControllerContext.HttpContext = _contextMock.Object;
    var actionResult = await orderController.Detail(fakeOrderId);

    //Assert
    var viewResult = Assert.IsType<ViewResult>(actionResult);
    Assert.IsAssignableFrom<Order>(viewResult.ViewData.Model);
}

Integrációs és funkcionális tesztek implementálása az egyes mikroszolgáltatásokhoz

Mint említettük, az integrációs tesztek és a funkcionális tesztek különböző célokkal és célokkal rendelkeznek. Az ASP.NET Core-vezérlők tesztelése során azonban mindkettő implementálása hasonló, ezért ebben a szakaszban az integrációs tesztekre összpontosítunk.

Az integrációs tesztelés biztosítja, hogy az alkalmazás összetevői megfelelően működjön összeállításkor. ASP.NET Core támogatja az integrációs tesztelést egységtesztelési keretrendszerek és egy beépített tesztwebhely használatával, amely a kérések hálózati terhelés nélkül történő kezelésére használható.

Az egységteszteléstől eltérően az integrációs tesztek gyakran alkalmazásinfrastruktúra-problémákat is érintenek, például adatbázist, fájlrendszert, hálózati erőforrásokat vagy webes kéréseket és válaszokat. Az egységtesztek hamis vagy szimulált objektumokat használnak ezen problémák helyett. Az integrációs tesztek célja azonban annak ellenőrzése, hogy a rendszer a várt módon működik-e ezekkel a rendszerekkel, így az integrációs teszteléshez nem használ hamis vagy hamis objektumokat. Ehelyett az infrastruktúrát is belefoglalja, például az adatbázis-hozzáférést vagy a szolgáltatáshívást más szolgáltatásokból.

Mivel az integrációs tesztek nagyobb kódszegmenseket végeznek, mint az egységtesztek, és mivel az integrációs tesztek infrastruktúra-elemekre támaszkodnak, általában nagyságrendekkel lassabbak, mint az egységtesztek. Ezért érdemes korlátozni, hogy hány integrációs tesztet írjon és futtasson.

ASP.NET Core tartalmaz egy beépített tesztwebhelyet, amely a HTTP-kérések hálózati terhelés nélkül történő kezelésére használható, ami azt jelenti, hogy gyorsabban futtathatja ezeket a teszteket, mint egy valódi webgazda használata esetén. A tesztwebhely (TestServer) egy NuGet-összetevőben érhető el Microsoft.AspNetCore.TestHost néven. Az integrációs tesztprojektekbe is hozzáadható, és ASP.NET Core-alkalmazások üzemeltetésére használható.

Ahogy az alábbi kódban is látható, a ASP.NET Core-vezérlők integrációs tesztjeinek létrehozásakor a vezérlőket a tesztgazda segítségével példányosíthatja. Ez a funkció hasonlít egy HTTP-kéréshez, de gyorsabban fut.

public class PrimeWebDefaultRequestShould
{
    private readonly TestServer _server;
    private readonly HttpClient _client;

    public PrimeWebDefaultRequestShould()
    {
        // Arrange
        _server = new TestServer(new WebHostBuilder()
           .UseStartup<Startup>());
        _client = _server.CreateClient();
    }

    [Fact]
    public async Task ReturnHelloWorld()
    {
        // Act
        var response = await _client.GetAsync("/");
        response.EnsureSuccessStatusCode();
        var responseString = await response.Content.ReadAsStringAsync();
        // Assert
        Assert.Equal("Hello World!", responseString);
    }
}

További erőforrások

Szolgáltatástesztek implementálása többtárolós alkalmazáson

Ahogy korábban említettük, a többtárolós alkalmazások tesztelése során az összes mikroszolgáltatásnak a Docker-gazdagépen vagy a tárolófürtön belül kell futnia. A több mikroszolgáltatást érintő, több műveletet tartalmazó teljes körű szolgáltatástesztekhez a docker-compose up futtatásával kell üzembe helyeznie és elindítania az egész alkalmazást a Docker-gazdagépen (vagy hasonló mechanizmust, ha vezénylőt használ). Miután a teljes alkalmazás és annak összes szolgáltatása fut, teljes körű integrációs és funkcionális teszteket hajthat végre.

Van néhány módszer, amelyet használhat. Az alkalmazás megoldásszinten való üzembe helyezéséhez használt docker-compose.yml fájlban bővítheti a belépési pontot a dotnet-teszt használatához. Használhat egy másik írási fájlt is, amely a teszteket a megcélzott képen futtatná. Ha egy másik összeállítási fájlt használ az integrációs tesztekhez, amelyek tartalmazzák a mikroszolgáltatásokat és a tárolókon lévő adatbázisokat, a tesztek futtatása előtt győződjön meg arról, hogy a kapcsolódó adatok mindig az eredeti állapotba kerülnek.

Miután a levélírási alkalmazás működik, kihasználhatja a töréspontokat és a kivételeket, ha a Visual Studiót futtatja. Vagy automatikusan futtathatja az integrációs teszteket a CI-folyamatban az Azure DevOps Servicesben vagy bármely más, Docker-tárolókat támogató CI/CD-rendszerben.

Tesztelés az eShopOnContainersben

A referenciaalkalmazási (eShopOnContainers) teszteket nemrég átalakították, és most négy kategória van:

  1. Egységtesztek, csak egyszerű régi normál egységtesztek, amelyek a {MicroserviceName}-ban találhatók. UnitTests-projektek

  2. Mikroszolgáltatások funkcionális/integrációs tesztjei, amelyek az egyes mikroszolgáltatások infrastruktúráját is magukban foglalják, de elkülönítve vannak a többitől, és a {MicroserviceName} tartalmazza. FunctionalTests-projektek .

  3. Alkalmazásfunkciós/integrációs tesztek, amelyek a mikroszolgáltatások integrációjára összpontosítanak, több mikroszolgáltatást alkalmazó tesztesetekkel. Ezek a tesztek az Application.FunctionalTests projektben találhatók.

Bár az egység- és integrációs tesztek a mikroszolgáltatás-projekt tesztmappájában vannak rendszerezve, az alkalmazás- és terheléstesztek a gyökérmappában külön vannak kezelve, ahogyan az a 6–25. ábrán látható.

Képernyőkép a VS-ről, amely rámutat néhány tesztprojektre a megoldásban.

6–25. ábra. Mappaszerkezet tesztelése az eShopOnContainersben

A mikroszolgáltatás- és alkalmazásfunkciós/integrációs tesztek a Visual Studióban futnak a normál tesztfuttatóval, de először el kell indítania a szükséges infrastruktúra-szolgáltatásokat a megoldásteszt mappában található docker-compose fájlokkal:

docker-compose-test.yml

version: '3.4'

services:
  redis.data:
    image: redis:alpine
  rabbitmq:
    image: rabbitmq:3-management-alpine
  sqldata:
    image: mcr.microsoft.com/mssql/server:2017-latest
  nosqldata:
    image: mongo

docker-compose-test.override.yml

version: '3.4'

services:
  redis.data:
    ports:
      - "6379:6379"
  rabbitmq:
    ports:
      - "15672:15672"
      - "5672:5672"
  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5433:1433"
  nosqldata:
    ports:
      - "27017:27017"

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

A funkcionális/integrációs tesztek futtatásához tehát először ezt a parancsot kell futtatnia a megoldásteszt mappából:

docker-compose -f docker-compose-test.yml -f docker-compose-test.override.yml up

Mint látható, ezek a docker-compose fájlok csak a Redis, a RabbitMQ, az SQL Server és a MongoDB mikroszolgáltatásokat indítják el.

További erőforrások

Előzőkövetkező