MVC uygulamalarını Test ASP.NET Core
"Ürününüzün birim testini beğenmezseniz, büyük olasılıkla müşterileriniz test etmek zorunda kalmaz." _Deðeri
Herhangi bir karmaşıklığın yazılımı, değişikliklere yanıt olarak beklenmedik yollarla başarısız olabilir. Bu nedenle, en önemsiz (veya en az kritik) uygulamalar için değişiklik yaptıktan sonra test edilmesi gerekir. El ile test etme, yazılımın test edilmesine yönelik en yavaş ve en ucuz yoldur. Ne yazık ki, uygulamalar test edilebilir olacak şekilde tasarlanmamışsa, kullanılabilir tek yol olabilir. Bölüm 4 ' te bulunan mimari ilkeleri izlemek için yazılan uygulamalar Unit Instable olmalıdır. ASP.NET Core uygulamalar otomatik tümleştirme ve işlevsel testi 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üzey test birim sınamadır. 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 kısmını sınar. Bu, olmadığı bazı şeyleri listeleyerek daha ayrıntılı bir şekilde açıklayabilir. Birim testi, kodunuzun bağımlılıklarla veya altyapıyla nasıl çalıştığını test etmez. Bu, tümleştirme sınamalarıdır. Bir birim testi, kodunuzun yazıldığı çerçeveyi test etmez; Bunun çalıştığını varsaymalı veya buldıysanız, bir hata dosyaz ve bir geçici çözüm kodlayın. 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, dış bağımlılıklar olmadan yalnızca kodunuzun tek bir birimini test ettikleri ve son derece hızlı yürütmemelidir. Bu nedenle, birkaç saniye içinde yüzlerce birim testinin test paketlerini çalıştırabilmelisiniz. Her bir paylaşılan kaynak denetimi deposuna her gönderim yapmadan önce ve yapı sunucunuzdaki her bir otomatik derleme ile, bunları sık sık ç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 kısmını yine de test etmek isteyeceksiniz. Ayrıca, uygulamanızın bağımlılıkları tamamen çözümlendiğinde kodunuzun katmanlarınızın bekledikleri gibi etkileşimde bulunduğunu doğrulamanız gerekir. Bu işlevsellik, tümleştirme testlerinin sorumluluğundadır. Genellikle dış bağımlılıklara ve altyapıya bağlı olduklarından, tümleştirme testlerinin daha yavaş ve birim testlerinin ayarlanmasından daha zor olma eğilimindedir. Bu nedenle, tümleştirme testlerinde birim testleriyle test edilmiş şeyleri test etmeyi önönüne almalısınız. Belirli bir senaryoyu birim testi ile test edebilirsiniz, onu bir birim testiyle test etmelisiniz. Bu durumda, bir tümleştirme testi kullanmayı göz önünde bulundurun.
Tümleştirme testlerinde genellikle birim testlerinden daha karmaşık kurulum ve Teari yordamları olur. Örneğin, gerçek bir veritabanına yönelik bir tümleştirme testi, her test çalıştırılmadan önce veritabanını bilinen bir duruma döndürmek için bir yönteme ihtiyaç duyar. Yeni testler eklendikçe ve üretim veritabanı şeması geliştikçe, bu test betikleri boyut ve karmaşıklık bakımından büyümeye eğilimindedir. Birçok büyük sistemde, paylaşılan kaynak denetimi değişikliklerini iade etmeden önce, geliştirici iş istasyonlarında tümleştirme testlerinin tam paketlerinin çalıştırılabilmesi pratik değildir. Bu durumlarda, tümleştirme testleri bir yapı sunucusu üzerinde ç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ıda, birim testlerine kıyasla işlevsel testlerin nasıl düşündüğleriyle ilgili yararlı bir benzerleme vurguladı sunulmaktadır:
"Bir sistemin geliştirilmesi birçok kez bir evin oluşturulmasına sahiptir. Bu benzerleme vurguladı oldukça doğru olmasa da, birim ve işlev testleri arasındaki farkı anlamak amacıyla onu genişletebiliriz. Birim testi, evin yapım sitesini ziyaret eden bir yapı denetçisine benzerdir. BT, temel, çerçevelendirme, elektrik, sıhhi tesisat gibi çeşitli iç sistemlere odaklanılmıştır. Evin bölümlerinin doğru ve güvenli şekilde çalışmasını sağlar (testler) ve derleme kodunu karşılayın. Bu senaryodaki işlevsel testler, aynı yapı sitesini ziyaret eden Homeowner 'a benzerdir. İç sistemlerin uygun şekilde davrandığını varsayar, derleme denetçisi görevini gerçekleştiriyor. Homeowner, bu evinizde ne kadar canlı hale görüneceğine odaklanılmıştır. Evin nasıl göründüğü, çeşitli odaların rahat bir boyut olduğu konusunda endişe duymaktadır, evin aile ihtiyaçlarına uyum sağlaması, Windows 'un sabah güneyi yakalamak için iyi bir nokta halinde. Homeowner, evinizde işlevsel testler gerçekleştiriyor. Kullanıcının perspektifi vardır. Yapı denetçisi, evinizde birim testlerini gerçekleştiriyor. Oluşturucunun perspektifi vardır. "
Kaynak: birim testi ve Işlev testlerine karşı
"Geliştirici olarak" geliştirici olarak söyliyoruz, iki şekilde başarısız oldu: bir şeyi yanlış oluşturacağız veya yanlış bir şey oluşturacağız. " Birim testleri, şeyi doğru bir şekilde oluşturduğunuzu güvence altına alarak, işlevsel sınamalar, doğru şeyi oluşturduğunuzdan emin olmanızı sağlamaktır.
İşlevsel testler sistem düzeyinde çalıştığından, bazı Kullanıcı Arabirimi Otomasyonu gerektirebilir. Tümleştirme testlerine benzer şekilde, genellikle bir tür test altyapısıyla da çalışırlar. Bu etkinlik, birim ve tümleştirme sınamalarından daha yavaş ve daha Brittle sağlar. Sistemin kullanıcıların beklediği şekilde davranmakta olduğundan emin olmanız gerektiği için yalnızca birçok işlevsel teste sahip olmanız gerekir.
Piramit test ediliyor
Marwler, Şekil 9-1 ' de gösterilen bir örnek olan test piramit hakkında yazdı.
Şekil 9-1. Piramit test ediliyor
Piramit 'in farklı katmanları ve bunların göreli boyutları, farklı test türlerini ve uygulamanız için kaç tane yazmanız gerektiğini temsil eder. Görebileceğiniz gibi, öneri, daha küçük bir tümleştirme testi katmanı tarafından desteklenen, daha küçük bir işlevsel test katmanı ile desteklenen, büyük miktarda birim testi olan bir temeldir. Her katmanın ideal olması için yalnızca daha düşük bir katmanda yeterince gerçekleştirilemediği testlerin olması gerekir. Belirli bir senaryo için hangi tür teste ihtiyacınız olduğuna karar verirken, testi piramit ' i göz önünde bulundurun.
Test edilecek
Otomatikleştirilmiş testler yazma konusunda deneyimli geliştiriciler için sık karşılaşılan bir sorun test edilecek. İyi bir başlangıç noktası, koşullu mantığı test etmek için kullanılır. Bir koşullu ifadeye (Else, Switch, vb.) göre değişen davranışlardan herhangi bir yerde, belirli koşullarda doğru davranışı onaylamak için en az birkaç test ile birlikte gelebilmelisiniz. Kodunuzun hata koşulları varsa, kod aracılığıyla "mutlu yol" için en az bir test yazmak iyi olur (hata olmadan) ve uygulamanın hata durumunda beklendiği gibi davrandığını doğrulamak için en az bir test (hata olmadan) ve "Sad yol" (hatalar veya tipik sonuçlar içeren) Son olarak, kod kapsamı gibi ölçümlere odaklanmak yerine başarısız olan test işlemleri üzerinde odaklanmayı deneyin. Daha fazla kod kapsamı, genellikle daha küçüktür. Ancak, karmaşık ve iş açısından kritik bir yöntemin birkaç testini yazmak genellikle test kod kapsamı ölçümlerini geliştirmek için otomatik özellikler için testlerin yazılmasından daha iyi bir zaman kullanmaktır.
Test projelerini düzenleme
Test projeleri düzenlenebilir, ancak sizin için en iyi şekilde kullanılabilir. Testleri türe (birim testi, tümleştirme testi) ve test ettikleri öğeleri (projeye göre, ad alanına göre) ayırmak iyi bir fikirdir. Bu ayırmaların tek bir test projesi veya birden çok test projesi içindeki klasörlerden oluşan bir tasarım kararı olup olmadığı. Bir proje en basit, ancak birçok test içeren büyük projeler için veya farklı test kümelerini daha kolay çalıştırmak için, farklı test projelerine sahip olmak isteyebilirsiniz. Birçok ekip test projelerini test ettikleri projeye göre düzenler, ancak bu, birkaç projeden daha fazla projeye sahip olan uygulamalar çok sayıda test projesine neden olabilir, ancak bu, özellikle de her projede ne tür testlerin ne olduğuna göre bunları daha düşük bir şekilde kesebilirsiniz. Bir riskli yaklaşım, test projeleri içindeki her bir proje (ve sınıfı) test edilen bir proje (ve sınıf) belirtmek için bir proje türüne sahip olmalıdır.
Ortak bir yaklaşım, bir ' src ' klasörü altında uygulama projelerini ve uygulamanın test projelerini paralel bir ' test ' klasörü altında düzenlemenize yardımcı olur. bu kuruluşun kullanışlı olduğunu fark ederseniz, Visual Studio eşleşen çözüm klasörleri oluşturabilirsiniz.
Şekil 9-2. Çözümünüzde test organizasyonu
Tercih ettiğiniz test çerçevesini kullanabilirsiniz. xunit çerçevesi iyi çalışmaktadır ve tüm ASP.NET Core ve EF Core testlerin yazıldığı şeydir. şekil 9-3 ' de gösterilen şablonu kullanarak Visual Studio bir xunit test projesi ekleyebilir veya kullanarak clı kullanabilirsiniz dotnet new xunit .
Şekil 9-3. Visual Studio bir xunit Test Project ekleme
Test adlandırma
Testlerinizi tutarlı bir şekilde ve her testin ne yaptığını belirten adlarla birlikte olarak adlar girin. Çok başarılı bir yaklaşım benim için test sınıflarını test etme yöntemine ve sınıfına göre adlarını verdim. Bu yaklaşım birçok küçük test sınıfına neden olur ancak her testin neden sorumlu olduğunu son derece net bir şekilde ifade ediyor. Test sınıfı adı ayar ile, 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ışı vereceği tüm girişleri veya varsayımları içermeli. Bazı örnek test adları:
CatalogControllerGetImage.CallsImageServiceWithIdCatalogControllerGetImage.LogsWarningGivenImageMissingExceptionCatalogControllerGetImage.ReturnsFileResultWithBytesGivenSuccessCatalogControllerGetImage.ReturnsNotFoundResultGivenImageMissingException
Bu yaklaşımın bir varyasyonu, her test sınıfı adını "Olmalı" ile sona erer ve zaman zamanını biraz değiştiren:
CatalogControllerGetImageŞu şekilde olması gerekir:.ÇağrısıImageServiceWithIdCatalogControllerGetImageŞu şekilde olması gerekir:.GünlükWarningGivenImageMissingException
Bazı takımlar ikinci adlandırma yaklaşımını biraz daha ayrıntılı bulsa da daha net bulur. Her durumda, bir veya daha fazla test başarısız olduğunda, adları tarafından hangi örneklerin başarısız olduğu açıkça belli olması için test davranışıyla ilgili içgörü sağlayan bir adlandırma kuralı kullanmayı deneyin. Testlerinizi ControllerTests.Test1 gibi bir şekilde adlandırmaktan kaçının çünkü bu adlar test sonuçlarında gördüğünüzde hiçbir değer sunamaz.
Yukarıdaki gibi çok sayıda küçük test sınıfı üreten bir adlandırma kuralını kullanırsanız, klasörleri ve ad alanlarını kullanarak testlerinizi daha fazla düzenlemeniz iyi bir fikirdir. Şekil 9-4'te, testleri çeşitli test projelerinde klasöre göre düzenlemeye yönelik bir yaklaşım bulunur.
Şekil 9-4. Test edilen sınıfa göre klasöre göre test sınıflarını düzenleme.
Belirli bir uygulama sınıfında test edilen birçok yöntem (ve bu nedenle çok sayıda test sınıfı) varsa, bu sınıfları uygulama sınıfına karşılık gelen bir klasöre yer olması mantıklı olabilir. Bu kuruluş, dosyaları başka bir yerde klasörlere düzenlemeden farklı değildir. Birçok başka dosya içeren bir klasörde üç veya dörtten fazla ilişkili dosya varsa, bunları kendi alt klasörlerine taşımak genellikle yararlı olur.
Birim testi ASP.NET Core uygulamaları
İyi tasarlanmış bir ASP.NET Core uygulamasında karmaşıklığın ve iş mantığının çoğu iş varlıklarına ve çeşitli hizmetlere kapsüller. MVC ASP.NET Core denetleyicileri, filtreleri, görünüm modelleri ve görünümleri ile birlikte birkaç birim testi gerekir. Verilen eylemin işlevlerinin büyük bir'i eylem yönteminin dışındadır. Yönlendirmenin veya genel hata işlemenin düzgün çalışıp çalışmay olmadığını test etme, birim testi ile etkili bir şekilde yapılamay. Benzer şekilde, model doğrulama, kimlik doğrulaması ve yetkilendirme filtreleri dahil olmak üzere tüm filtreler, denetleyicinin eylem yöntemini hedef alan bir testle birim test edilemez. Bu davranış kaynakları olmadan, çoğu eylem yöntemi önemsiz bir şekilde küçük olmalıdır ve bu yöntemler, bunların toplu işlerini kullanan denetleyiciden bağımsız olarak test edilebilir hizmetlere sunar.
Bazen kodunuzu birim testi için yeniden düzenlemeniz gerekir. Bu etkinlik genellikle soyutlamaları tanımlamayı ve doğrudan altyapıya kodlamak yerine test etmek için kullanmak üzere kodda özete erişmek için bağımlılık ekleme kullanmayı içerir. Örneğin, görüntüleri görüntülemek için bu kolay eylem yöntemini düşünün:
[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ığı System.IO.File nedeniyle zorlaştı. Bu davranışı test etmek için beklendiği gibi çalışır ancak bunu gerçek dosyalarla yapmak bir tümleştirme testidir. Bu yöntemin yolunu birim testiyle test etmek yerine kısa süre içinde işlevsel bir testle bu testi nasıl — yapacaklarını görmektesiniz.
Dosya sistemi davranışını doğrudan birim testiyle test amıyorsanız ve yolu testamıyorsanız test etmek için ne vardır? Birim testini mümkün hale etmek için yeniden düzenlemeden sonra hata işleme gibi bazı test durumlarını ve eksik davranışları keşfedersiniz. Bir dosya bulunamasa yöntemi ne yapar? Ne yapacak? Bu örnekte, yeniden düzenleme yöntemi şu şekildedir:
[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 eklemeler. Artık, eylem yöntemine geçirilen kimliğin 'e geçirileb ve sonuçta elde edilen baytların FileResult'un bir parçası olarak döndürülerek test _imageService etmek için kullanabilirsiniz. Ayrıca hata günlüğünün beklendiği gibi olup olmadığını ve görüntü eksikse bir sonuç döndürülerek bu davranışın önemli bir uygulama davranışı (yani, yalnızca geliştiricinin bir sorunu tanılamak için ekleyeceği geçici kod değil) olduğunu da NotFound sınayabilirsiniz. Gerçek dosya mantığı ayrı bir uygulama hizmetine taşındı ve eksik dosya durumunda uygulamaya özgü bir özel durum dönecek şekilde genişletilmiştir. Tümleştirme testi kullanarak bu uygulamanın bağımsız olarak testini sebilirsiniz.
Çoğu durumda, denetleyicileriniz içinde genel özel durum işleyicileri kullanmak istemeniz gerekir, bu nedenle bu işleyicilerde mantık miktarı çok az olmalı ve muhtemelen birim testlerine değmeli. İşlevsel testleri ve aşağıda açıklanan sınıfı kullanarak denetleyici eylemlerinizin TestServer testlerinin çoğunu gerçekleştirin.
Tümleştirme testi ASP.NET Core uygulamaları
ASP.NET Core uygulamalarınıza yönelik tümleştirme testlerinin çoğu, Altyapı projesinde tanımlanan test hizmetleri ve diğer uygulama türleridir. Örneğin, altyapı projesinde EF Core veri erişim sınıflarından beklediğiniz verileri başarıyla güncelleştirerek ve alırken test etmek için bir testte bulundurabilirsiniz. MVC projenizin doğru şekilde ASP.NET Core test etmek için en iyi yol, test ana bilgisayarını çalıştıran uygulamanıza karşı çalışan işlevsel testlerledir.
İşlevsel test ASP.NET Core uygulamaları
Bu ASP.NET Core için TestServer sınıf, işlevsel testlerin yaz kolay yaznını kolaylaştırır. (veya ) kullanarak doğrudan (normalde uygulamanız için olduğu gibi) veya TestServer WebHostBuilder HostBuilder WebApplicationFactory türüyle (sürüm 2.1'den itibaren kullanılabilir) yapılandırabilirsiniz. Test ana bilgisayarını üretim ana bilgisayarını mümkün olduğunca yakından eşleşmeye çalışarak test alıştırması davranışını uygulamanın üretimde yapacakları gibi yapın. sınıfı, Görünümler gibi statik kaynağı bulmak için ASP.NET Core WebApplicationFactory TestServer'ın ContentRoot'ünü yapılandırmak için yararlıdır.
Basit işlevsel testler oluşturmak için web uygulamanıza sınıfı olan uygulamasını IClassFixture\<WebApplicationFactory\<TEntry>> TEntry uygulayan bir test sınıfı Startup oluşturabilirsiniz. Bu arabirim kullanılabilir durumda olduğu için test sonuçlarınız fabrikanın yöntemini kullanarak bir istemci CreateClient oluşturabilir:
public class BasicWebTests : IClassFixture<WebApplicationFactory<Startup>>
{
protected readonly HttpClient _client;
public BasicWebTests(WebApplicationFactory<Startup> factory)
{
_client = factory.CreateClient();
}
// write tests that use _client
}
Genellikle, her test çalıştırılamadan önce, uygulamayı bellek içinde bir veri deposu kullanmak üzere yapılandırma ve ardından uygulamayı test verileriyle çekirdeğini yapılandırma gibi bazı ek yapılandırmalar yapmak gerekir. Bu işlevi elde etmek için kendi alt sınıfını oluşturun ve WebApplicationFactory\<TEntry> yöntemini geçersiz ConfigureWebHost kılın. 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'i kullanarak bir istemci oluşturabilir ve ardından bu istemci örneğini kullanarak uygulamaya istekte olabilir. Uygulamanın çekirdeğini, testin onaylarının bir parçası olarak kullanılmaktadır. Aşağıdaki test, eShopOnWeb uygulamasının giriş sayfasının doğru yükleniyor olduğunu doğrular ve çekirdek verileri kapsamında uygulamaya eklenmiş bir ürün listesi 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, tüm ASP.NET Core, filtreler ve bağlayıcılar dahil olmak Razor Pages MVC /Razor Pages uygulama yığınının tamamını içerir. Belirli bir yol ("/") tarafından beklenen başarı durumu kodunun ve HTML çıkışının döndür olduğunu doğrular. Bunu gerçek bir web sunucusu ayarlamadan yapar ve test için gerçek bir web sunucusu kullanmanın (örneğin güvenlik duvarı ayarlarıyla ilgili sorunlar) neden olduğu güvenlik açıklarından kaçınır. TestServer'da çalıştırilen işlevsel testler genellikle tümleştirme ve birim testlerine göre daha yavaştır, ancak ağ üzerinden test web sunucusuna çalıştıracak testlerden çok daha hızlıdır. Uygulama ön uç yığınının beklendiği gibi çalışa olduğundan emin olmak için işlevsel testleri kullanın. Bu testler, özellikle de denetleyicileriniz veya sayfalarda yineleme bulur ve filtre ekleyerek yinelemeyi ele alamanız gerekir. İdeal olarak, bu yeniden düzenleme uygulamanın davranışını değiştirmez ve bir işlev testi paketi bu durumu doğrular.
Başvurular – MVC ASP.NET Core test edin
- ASP.NET Core'de test etme
https://docs.microsoft.com/aspnet/core/testing/- Birim Testi Adlandırma Kuralı
https://ardalis.com/unit-test-naming-convention- Test EF Core
https://docs.microsoft.com/ef/core/miscellaneous/testing/- ASP.NET Core'de tümleştirme testleri
https://docs.microsoft.com/aspnet/core/test/integration-tests