Aracılığıyla paylaş

ASP.NET Core MVC uygulamalarını test edin

  • Makale

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan ASP.NET Core ve Azure ile Modern Web Uygulamaları Mimarisi adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

Architect Modern Web Applications with ASP.NET Core and Azure eBook cover thumbnail.

"Ürününüzün birim testini beğenmezseniz, büyük olasılıkla müşterileriniz de test etmek istemez." _-Anonim-

Herhangi bir karmaşıklıkta yazılım, değişikliklere yanıt olarak beklenmeyen yollarla başarısız olabilir. Bu nedenle, en önemsiz (veya en az kritik) uygulamalar dışında tüm uygulamalar için değişiklik yaptıktan sonra test yapılması gerekir. El ile test, yazılımı test etmenin en yavaş, en az güvenilir ve en pahalı yoludur. Ne yazık ki, uygulamalar test edilebilir olacak şekilde tasarlanmamışsa, kullanılabilen tek test aracı bu olabilir. 4. bölümde belirtilen mimari ilkeleri izlemek için yazılan uygulamalar büyük ölçüde birim test edilebilir olmalıdır. ASP.NET Core uygulamaları otomatik tümleştirmeyi ve işlevsel testleri destekler.

Otomatikleştirilmiş test türleri

Yazılım uygulamaları için birçok tür otomatikleştirilmiş test vardır. En basit, en düşük düzeyli test, birim testidir. Biraz daha yüksek bir düzeyde tümleştirme testleri ve işlevsel testler vardır. Ui testleri, yük testleri, stres testleri ve duman testleri gibi diğer test türleri bu belgenin kapsamı dışındadır.

Birim testleri

Birim testi, uygulamanızın mantığının tek bir bölümünü test ediyor. Olmayan bazı öğeleri listeleyerek bunu daha ayrıntılı bir şekilde açıklayabilirsiniz. Birim testi, kodunuzun bağımlılıklarla veya altyapıyla nasıl çalıştığını test etmez; tümleştirme testleri bunun içindir. Birim testi kodunuzun yazdığı çerçeveyi test etmez; çalıştığını varsaymalısınız veya işe yaramazsa bir hata oluşturup geçici bir çözüm kodlamalısınız. Birim testi tamamen bellekte ve işlemde çalışır. Dosya sistemi, ağ veya veritabanıyla iletişim kurmaz. Birim testleri yalnızca kodunuzu test etmelidir.

Birim testleri, kodunuzun yalnızca tek bir birimini test etmelerinden ve dış bağımlılık olmadan son derece hızlı yürütmeleri gerektiği gerçeğinden kaynaklanabilir. Bu nedenle, birkaç saniye içinde yüzlerce birim testinin test paketlerini çalıştırabilmeniz gerekir. Bunları sık sık, ideal olarak paylaşılan bir kaynak denetimi deposuna yapılan her göndermeden önce ve derleme sunucunuzdaki her otomatik derlemeyle çalıştırın.

Tümleştirme testleri

Veritabanları ve dosya sistemleri gibi altyapıyla etkileşim kuran kodunuzu kapsüllemek iyi bir fikir olsa da, bu kodun bir bölümüne sahip olmaya devam edebilirsiniz ve muhtemelen bunu test etmek isteyeceksiniz. Ayrıca, uygulamanızın bağımlılıkları tam olarak çözümlendiğinde kodunuzun katmanlarının beklediğiniz gibi etkileşime geçtiğini doğrulamanız gerekir. Bu işlev tümleştirme testlerinin sorumluluğundadır. Tümleştirme testleri genellikle dış bağımlılıklara ve altyapıya bağlı olduğundan, birim testlerine göre daha yavaş ve ayarlanması daha zor olma eğilimindedir. Bu nedenle, tümleştirme testlerinde birim testleriyle test edilebilecek şeyleri test etmekten kaçınmanız gerekir. Belirli bir senaryoya birim testiyle test edebilirseniz, bunu bir birim testiyle test etmelisiniz. Bunu yapamazsanız tümleştirme testi kullanmayı göz önünde bulundurun.

Tümleştirme testlerinin genellikle birim testlerinden daha karmaşık kurulum ve yok etme yordamları olacaktır. Örneğin, gerçek bir veritabanına ters giden bir tümleştirme testi, her test çalıştırması öncesinde veritabanını bilinen bir duruma döndürmenin bir yoluna ihtiyaç duyar. Yeni testler eklendikçe ve üretim veritabanı şeması geliştikçe, bu test betiklerinin boyutu ve karmaşıklığı artacaktır. Birçok büyük sistemde, paylaşılan kaynak denetimindeki değişiklikleri denetlemeden önce geliştirici iş istasyonlarında tümleştirme testlerinin tam paketlerini çalıştırmak pratik değildir. Bu gibi durumlarda tümleştirme testleri bir derleme sunucusunda çalıştırılabilir.

İşlevsel testler

Tümleştirme testleri, sistemin bazı bileşenlerinin birlikte düzgün çalıştığını doğrulamak için geliştiricinin perspektifinden yazılır. İşlevsel testler kullanıcının perspektifinden yazılır ve gereksinimlerine göre sistemin doğruluğunu doğrular. Aşağıdaki alıntı, birim testlerine kıyasla işlevsel testler hakkında nasıl düşünüleceğini gösteren kullanışlı bir benzetme sunar:

"Bir sistemin gelişimi çoğu zaman bir evin binasına benzer. Bu benzetme tam olarak doğru olmasa da, birim ve işlevsel testler arasındaki farkı anlamak amacıyla genişletebiliriz. Birim testi, bir evin şantiyesini ziyaret eden bir yapı denetçisine benzer. Evin çeşitli iç sistemleri, temel, çerçeveleme, elektrik, tesisat vb. üzerine odaklanmıştır. Evin bölümlerinin doğru ve güvenli bir şekilde çalışmasını, yani yapı kodunu karşılamasını sağlar (testler). Bu senaryodaki işlevsel testler, aynı inşaat alanını ziyaret eden ev sahibine benzer. İç sistemlerin uygun şekilde davranacağını, bina denetçisinin görevini yerine getireceğini varsayar. Ev sahibi, bu evde yaşamanın nasıl bir şey olduğuna odaklanmış. Evin nasıl göründüğüyle ilgileniyor, çeşitli odalar rahat bir boyutta mı, ev ailenin ihtiyaçlarına uyuyor mu, sabah güneşini yakalamak için iyi bir noktadaki pencereler. Ev sahibi evde işlevsel testler yapıyor. Kullanıcının bakış açısına sahip. Bina denetçisi evde birim testleri yapıyor. O, inşaatçının bakış açısına sahip."

Kaynak: Birim Testi ve İşlevsel Testler

"Geliştiriciler olarak iki şekilde başarısız oluyoruz: bu şeyi yanlış inşa ediyoruz veya yanlış bir şey oluşturuyoruz" demek hoşuma gidiyor. Birim testleri, doğru şeyi oluşturduğunuzdan emin olun; işlevsel testler doğru şeyi oluşturduğunuzdan emin olun.

İşlevsel testler sistem düzeyinde çalıştığından, bir derece kullanıcı arabirimi otomasyonu gerektirebilir. Tümleştirme testlerinde olduğu gibi, genellikle bir tür test altyapısıyla da çalışırlar. Bu etkinlik, birim ve tümleştirme testlerinden daha yavaş ve daha kırılgan olmalarını sağlar. Sistemin kullanıcıların beklediği gibi davranacağından emin olmak için yalnızca ihtiyacınız olan sayıda işlevsel teste sahip olmanız gerekir.

Piramit Test Etme

Martin Fowler, örnek olarak Şekil 9-1'de gösterilen test piramidi hakkında yazdı.

Testing Pyramid

Şekil 9-1. Piramit Test Etme

Piramidin farklı katmanları ve bunların göreli boyutları, farklı test türlerini ve uygulamanız için kaç test yazmanız gerektiğini temsil eder. Gördüğünüz gibi, daha küçük bir tümleştirme testi katmanı tarafından desteklenen ve daha da küçük işlevsel test katmanına sahip olan büyük bir birim testi tabanına sahip olmanız önerilir. Her katmanın ideal olarak yalnızca alt katmanda yeterince gerçekleştirilemeyen testleri olmalıdır. Belirli bir senaryo için ihtiyacınız olan test türüne karar vermeye çalışırken test piramidini aklınızda bulundurun.

Test etmek için gerekenler

Otomatikleştirilmiş testler yazma konusunda deneyimsiz olan geliştiriciler için sık karşılaşılan bir sorun, test edilmesi gerekenleri bulmaktır. İyi bir başlangıç noktası, koşullu mantığı test etmektir. Koşullu deyim temelinde değişen davranışa sahip bir yönteminiz varsa (if-else, switch vb.), belirli koşullar için doğru davranışı onaylayan en az birkaç test yapabilmeniz gerekir. Kodunuz hata koşullarına sahipse, kod aracılığıyla "mutlu yol" için en az bir test (hata olmadan) ve uygulamanızın hatalar karşısında beklendiği gibi davrandığını onaylamak için "üzgün yol" (hatalar veya atipik sonuçlarla) için en az bir test yazmak iyi olur. Son olarak, kod kapsamı gibi ölçümlere odaklanmak yerine başarısız olabilecek şeyleri test etmeye odaklanmayı deneyin. Genellikle daha fazla kod kapsamı daha azdan iyidir. Ancak karmaşık ve iş açısından kritik bir yöntemin birkaç testini daha yazmak, yalnızca test kodu kapsamı ölçümlerini geliştirmek için otomatik özelliklere yönelik testler yazmaktan daha iyi bir zaman kullanımıdır.

Test projelerini düzenleme

Test projeleri düzenlenebilir ancak sizin için en iyi sonucu verebilir. Testleri türe (birim testi, tümleştirme testi) ve test ettikleri şeye göre (projeye, ad alanına göre) ayırmak iyi bir fikirdir. Bu ayırmanın tek bir test projesindeki klasörlerden mi yoksa birden çok test projesinden mi oluştuğu tasarım kararıdır. Bir proje en basittir, ancak çok sayıda testi olan büyük projeler için veya farklı test kümelerini daha kolay çalıştırmak için birkaç farklı test projesine sahip olmak isteyebilirsiniz. Birçok ekip, test ettikleri projeye göre test projelerini düzenler. Bu, birkaç projeden fazla projesi olan uygulamalar için çok sayıda test projesine neden olabilir, özellikle de bunları her projede ne tür testlerin bulunduğuna göre ayırmaya devam ederseniz. Risk altındaki bir yaklaşım, test projelerinin (ve sınıfın) test edildiğini belirtmek için test projeleri içindeki klasörlerle uygulama başına bir test türüne sahip olmaktır.

Yaygın bir yaklaşım, uygulama projelerini bir 'src' klasörü altında, uygulamanın test projelerini ise paralel bir 'testler' klasörü altında düzenlemektir. Bu kuruluşu yararlı bulursanız, Visual Studio'da eşleşen çözüm klasörleri oluşturabilirsiniz.

Test organization in your solution

Şekil 9-2. Çözümünüzde kuruluşu test edin

Tercih ettiğiniz test çerçevelerini kullanabilirsiniz. xUnit çerçevesi iyi çalışır ve tüm ASP.NET Core ve EF Core testlerinin yazıldıklarındandır. Şekil 9-3'te gösterilen şablonu kullanarak Visual Studio'da veya kullanarak dotnet new xunitCLI'dan bir xUnit test projesi ekleyebilirsiniz.

Add an xUnit Test Project in Visual Studio

Şekil 9-3. Visual Studio'da xUnit Test Projesi ekleme

Test adlandırma

Testlerinizi tutarlı bir şekilde adlandırarak her testin ne yaptığını gösteren adlar ekleyin. Başarılı olduğum bir yaklaşım, test sınıflarını test ettikleri sınıfa ve yönteme göre adlandırmaktır. Bu yaklaşım birçok küçük test sınıfına neden olur, ancak her testin ne için sorumlu olduğunu son derece net hale getirir. Test sınıfı adı ayarlandıktan sonra, test edilecek sınıfı ve yöntemi tanımlamak için test yöntemi adı, test edilen davranışı belirtmek için kullanılabilir. Bu ad beklenen davranışı ve bu davranışı vermesi gereken girişleri veya varsayımları içermelidir. Bazı örnek test adları:

  • CatalogControllerGetImage.CallsImageServiceWithId

  • CatalogControllerGetImage.LogsWarningGivenImageMissingException

  • CatalogControllerGetImage.ReturnsFileResultWithBytesGivenSuccess

  • CatalogControllerGetImage.ReturnsNotFoundResultGivenImageMissingException

Bu yaklaşımın bir varyasyonu, her test sınıfı adını "Should" ile sonlandırır ve gergini biraz değiştirir:

  • CatalogControllerGetImageÇağrılmalı.ImageServiceWithId

  • CatalogControllerGetImageGünlüğe Kaydetmeli.WarningGivenImageMissingException

Bazı takımlar ikinci adlandırma yaklaşımını daha net, ancak biraz daha ayrıntılı buluyor. Her durumda, test davranışı hakkında içgörü sağlayan bir adlandırma kuralı kullanmayı deneyin; böylece bir veya daha fazla test başarısız olduğunda, hangi durumların başarısız olduğu adlarından açıkça anlaşılır. Test sonuçlarınızda gördüğünüzde bu adlar hiçbir değer sunmayacağı için testlerinizi ControllerTests.Test1 gibi belirsiz bir şekilde adlandırmaktan kaçının.

Yukarıdaki gibi çok sayıda küçük test sınıfı üreten bir adlandırma kuralını izlerseniz, klasörleri ve ad alanlarını kullanarak testlerinizi daha fazla düzenlemek iyi bir fikirdir. Şekil 9-4'de, çeşitli test projelerinde testleri klasöre göre düzenlemeye yönelik bir yaklaşım gösterilmektedir.

Organizing test classes by folder based on class being tested

Şekil 9-4. Test sınıflarını test edilen sınıfa göre klasöre göre düzenleme.

Belirli bir uygulama sınıfı test edilen birçok yönteme (ve dolayısıyla birçok test sınıfına) sahipse, bu sınıfları uygulama sınıfına karşılık gelen bir klasöre yerleştirmek mantıklı olabilir. Bu kuruluş, dosyaları başka bir yerde klasörler halinde düzenleme yönteminden farklı değildir. Başka birçok dosya içeren bir klasörde üç veya dörtten fazla ilişkili dosyanız varsa, bunları kendi alt klasörlerine taşımak genellikle yararlı olur.

ASP.NET Core uygulamaları için birim testi

İyi tasarlanmış bir ASP.NET Core uygulamasında karmaşıklık ve iş mantığının çoğu iş varlıkları ve çeşitli hizmetlerde kapsüllenir. ASP.NET Core MVC uygulamasının denetleyicileri, filtreleri, görünüm modelleri ve görünümleri ile birkaç birim testi gerektirmelidir. Belirli bir eylemin işlevlerinin çoğu eylem yönteminin dışındadır. Birim testiyle yönlendirme veya genel hata işlemenin düzgün çalışıp çalışmadığını test etme. Benzer şekilde, model doğrulama, kimlik doğrulama ve yetkilendirme filtreleri de dahil olmak üzere tüm filtreler, denetleyicinin eylem yöntemini hedefleyen bir testle birim testi yapılamaz. Bu davranış kaynakları olmadan, çoğu eylem yönteminin küçük olması ve çalışmalarının büyük bölümünü bunları kullanan denetleyiciden bağımsız olarak test edilebilecek hizmetlere devretmesi gerekir.

Bazen kodunuzu birim testi için yeniden düzenlemeniz gerekir. Bu etkinlik genellikle soyutlamaları tanımlamayı ve doğrudan altyapıya karşı kodlamak yerine test etmek istediğiniz koddaki özete erişmek için bağımlılık eklemeyi içerir. Örneğin, görüntüleri görüntülemek için bu kolay eylem yöntemini göz önünde bulundurun:

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

Bu yöntemin birim testi, dosya sisteminden okumak için kullandığı doğrudan bağımlılığıyla System.IO.Filezorlanır. Beklendiği gibi çalıştığından emin olmak için bu davranışı test edebilirsiniz, ancak bunu gerçek dosyalarla yapmak bir tümleştirme testidir. Bu yöntemin rotasını birim testiyle gerçekleştiremediğiniz de dikkate değer; kısa süre içinde bu testi işlevsel bir testle nasıl yapacağınızı göreceksiniz.

Dosya sistemi davranışını doğrudan birim testi yapamazsanız ve yolu test edemezseniz, test etmek için ne var? Birim testlerini mümkün kılmak için yeniden düzenleme yaptıktan sonra bazı test çalışmalarını ve hata işleme gibi eksik davranışları keşfedebilirsiniz. Bir dosya bulunamadığında yöntemi ne yapar? Ne yapmalı? Bu örnekte, yeniden düzenlenmiş yöntem şöyle görünür:

[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 ve _imageService her ikisi de bağımlılık olarak eklenir. Artık eylem yöntemine geçirilen kimliğin aynısının öğesine _imageServicegeçirildiğini ve sonuçta elde edilen baytların FileResult'un bir parçası olarak döndürüldüğünü test edebilirsiniz. Ayrıca hata günlüğünün beklendiği gibi gerçekleştiğini ve bu davranışın önemli bir uygulama davranışı (yani geliştiricinin sorunu tanılamak için eklediği geçici kod değil) varsayılarak görüntü eksikse bir NotFound sonuç döndürüldüğünü de test edebilirsiniz. Gerçek dosya mantığı ayrı bir uygulama hizmetine taşındı ve eksik bir dosya için uygulamaya özgü bir özel durum döndürecek şekilde genişletildi. Tümleştirme testi kullanarak bu uygulamayı bağımsız olarak test edebilirsiniz.

Çoğu durumda, denetleyicilerinizde genel özel durum işleyicileri kullanmak istersiniz, bu nedenle içindeki mantık miktarı en düşük düzeyde olmalı ve büyük olasılıkla birim testine değmemelidir. İşlevsel testleri ve TestServer aşağıda açıklanan sınıfı kullanarak denetleyici eylemlerini test etme işleminizin çoğunu yapın.

Tümleştirme testi ASP.NET Core uygulamaları

ASP.NET Core uygulamalarınızdaki tümleştirme testlerinin çoğu, Altyapı projenizde tanımlanan test hizmetleri ve diğer uygulama türleri olmalıdır. Örneğin, EF Core'un Altyapı projesinde bulunan veri erişim sınıflarınızdan beklediğiniz verileri başarıyla güncelleştirip alıp almadığını test edebilirsiniz. ASP.NET Core MVC projenizin doğru şekilde çalışıp çalışmadığını test etmenin en iyi yolu, test ana bilgisayarında çalışan uygulamanızda çalışan işlevsel testlerledir.

İşlevsel test ASP.NET Core uygulamaları

ASP.NET Core uygulamaları için TestServer sınıfı, işlevsel testleri yazmayı oldukça kolaylaştırır. Bir öğesini doğrudan (veya ) kullanarak WebHostBuilder (normalde uygulamanız için yaptığınız gibi) veya türüyle WebApplicationFactory (sürüm 2.1'den itibaren kullanılabilir) yapılandırabilirsinizTestServer.HostBuilder Test ana bilgisayarınızı üretim konağınızla mümkün olduğunca yakın bir şekilde eşleştirmeyi deneyin, böylece testleriniz uygulamanın üretimde yapacağına benzer bir davranış uygular. WebApplicationFactory sınıfı, ASP.NET Core tarafından Görünümler gibi statik kaynağı bulmak için kullanılan TestServer ContentRoot'unu yapılandırmak için yararlıdır.

uygulamasını uygulayan IClassFixture<WebApplicationFactory<TEntryPoint>>bir test sınıfı oluşturarak basit işlevsel testler oluşturabilirsiniz; burada TEntryPoint web uygulamanızın Startup sınıfıdır. Bu arabirim kullanıldığında test fikstürünüzün fabrikanın yöntemini kullanarak bir istemci oluşturması CreateClient gerekir:

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

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

  // write tests that use _client
}

İpucu

Program.cs dosyanızda en az API yapılandırması kullanıyorsanız, sınıf varsayılan olarak iç olarak bildirilir ve test projesinden erişilemez. Bunun yerine web projenizdeki diğer örnek sınıflarını seçebilir veya bunu Program.cs dosyanıza ekleyebilirsiniz:

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

Sık sık, her test çalışmadan önce sitenizin bazı ek yapılandırmasını gerçekleştirmek istersiniz. Örneğin, uygulamayı bellek içi veri deposu kullanacak şekilde yapılandırma ve ardından uygulamayı test verileriyle dağıtma. Bu işlevi elde etmek için kendi alt sınıfınızı WebApplicationFactory<TEntryPoint> oluşturun ve yöntemini geçersiz kılın ConfigureWebHost . Aşağıdaki örnek eShopOnWeb FunctionalTests projesindendir ve ana web uygulamasındaki testlerin bir parçası olarak kullanılır.

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

Testler, bu özel WebApplicationFactory'yi kullanarak bir istemci oluşturup bu istemci örneğini kullanarak uygulamaya istekte bulunarak kullanabilir. Uygulama, testin onaylarının bir parçası olarak kullanılabilecek veri tohumlarına sahip olur. Aşağıdaki test, eShopOnWeb uygulamasının giriş sayfasının doğru yüklendiğini doğrular ve tohum verilerinin bir parçası olarak uygulamaya eklenen bir ürün listesini içerir.

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

Bu işlevsel test, mevcut olabilecek tüm ara yazılım, filtreler ve bağlayıcılar dahil olmak üzere tam ASP.NET Core MVC / Razor Pages uygulama yığınını alıştırma yapar. Belirli bir yolun ("/") beklenen başarı durumu kodunu ve HTML çıkışını döndürdüğünü doğrular. Bunu gerçek bir web sunucusu ayarlamadan yapar ve test için gerçek bir web sunucusu kullanmanın karşılaşabileceği kırılganlığı önler (örneğin, güvenlik duvarı ayarlarıyla ilgili sorunlar). TestServer'da çalışan işlevsel testler genellikle tümleştirme ve birim testlerinden daha yavaştır, ancak ağ üzerinden test web sunucusuna çalıştırılacak testlerden çok daha hızlıdır. Uygulamanızın ön uç yığınının beklendiği gibi çalıştığından emin olmak için işlevsel testleri kullanın. Bu testler özellikle denetleyicilerinizde veya sayfalarınızda yinelenenleri bulduğunuzda ve filtre ekleyerek yinelemeyi ele aldığınızda kullanışlıdır. İdeal olarak, bu yeniden düzenleme uygulamanın davranışını değiştirmez ve işlevsel testlerden oluşan bir paket bunun böyle olduğunu doğrular.

Başvurular – ASP.NET Core MVC uygulamalarını test edin

Geriİleri