.NET कोर

Question

में यूनिट टेस्ट स्टार्टअप.cs कैसे करें। लोग .NET कोर 2 एप्लिकेशन में अपने Startup.cs कक्षाओं को यूनिट परीक्षण करने के बारे में कैसे जाते हैं? सभी कार्यक्षमता स्टेटिक एक्सटेंशन विधियों द्वारा प्रदान की जाती है जो नकली नहीं हैं?

आप उदाहरण के लिए इस ConfigureServices विधि लेते हैं:

public void ConfigureServices(IServiceCollection services) 
{ 
    services.AddDbContext<BlogContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))); 

    services.AddMvc(); 
} 

मैं परीक्षण कैसे लिख सकता हूँ यह सुनिश्चित करें कि AddDbContext (...) & AddMvc() कहा जाता है कर सकते हैं, के माध्यम से इस कार्यशीलता के सभी को लागू करने के विकल्प ऐसा लगता है कि एक्सटेंशन विधियों ने इसे अचूक बना दिया है?

Answer 1

ठीक है, अगर आप इस तथ्य को देखना चाहते हैं कि विस्तार विधि AddDbContext को services पर बुलाया गया था तो आप परेशानी में हैं। अच्छी बात यह है कि आपको वास्तव में वास्तव में इस तथ्य की जांच नहीं करनी चाहिए।

Startup कक्षा एक आवेदन composition root है। और जब एक रचना जड़ का परीक्षण करते हैं तो आप यह जांचना चाहते हैं कि यह वास्तव में रूट ऑब्जेक्ट्स (एएसपी.नेट कोर एप्लिकेशन के मामले में नियंत्रकों) के तत्कालता के लिए आवश्यक सभी निर्भरताओं को पंजीकृत करता है।

public class TestController : Controller 
{ 
    public TestController(ISomeDependency dependency) 
    { 
    } 
} 

आप की जाँच StartupISomeDependency के लिए प्रकार पंजीकृत किया गया है कि क्या कोशिश कर सकते:

आप निम्नलिखित नियंत्रक है कहो। लेकिन ISomeDependency के कार्यान्वयन के लिए आपको कुछ अन्य निर्भरताओं की भी आवश्यकता हो सकती है जिन्हें आपको जांचना चाहिए। आखिरकार आप एक परीक्षण के साथ समाप्त होते हैं जिसमें विभिन्न निर्भरताओं के लिए बहुत सारे चेक होते हैं लेकिन यह वास्तव में गारंटी नहीं देता है कि ऑब्जेक्ट रिज़ॉल्यूशन लापता निर्भरता अपवाद फेंक नहीं देगा। इस तरह के एक परीक्षण में बहुत अधिक मूल्य नहीं है।

एक दृष्टिकोण जो एक रचना जड़ का परीक्षण करते समय मेरे लिए अच्छा काम करता है वास्तविक निर्भरता इंजेक्शन कंटेनर का उपयोग करना है। फिर मैं उस पर एक रचना जड़ कहता हूं और जोर देता हूं कि रूट ऑब्जेक्ट का संकल्प फेंक नहीं देता है।

इसे शुद्ध यूनिट टेस्ट के रूप में नहीं माना जा सकता क्योंकि हम अन्य गैर-स्टब किए गए वर्ग का उपयोग करते हैं। लेकिन ऐसे परीक्षण, अन्य एकीकरण परीक्षणों के विपरीत, तेज़ और स्थिर हैं। और सबसे महत्वपूर्ण वे सही निर्भरता पंजीकरण के लिए वैध जांच का मूल्य लाते हैं। यदि ऐसा परीक्षण पास हो जाता है तो आप यह सुनिश्चित कर सकते हैं कि उत्पाद में ऑब्जेक्ट को सही ढंग से तुरंत चालू किया जाएगा।

[TestMethod] 
public void ConfigureServices_RegistersDependenciesCorrectly() 
{ 
    // Arrange 

    // Setting up the stuff required for Configuration.GetConnectionString("DefaultConnection") 
    Mock<IConfigurationSection> configurationSectionStub = new Mock<IConfigurationSection>(); 
    configurationSectionStub.Setup(x => x["DefaultConnection"]).Returns("TestConnectionString"); 
    Mock<Microsoft.Extensions.Configuration.IConfiguration> configurationStub = new Mock<Microsoft.Extensions.Configuration.IConfiguration>(); 
    configurationStub.Setup(x => x.GetSection("ConnectionStrings")).Returns(configurationSectionStub.Object); 

    IServiceCollection services = new ServiceCollection(); 
    var target = new Startup(configurationStub.Object); 

    // Act 

    target.ConfigureServices(services); 
    // Mimic internal asp.net core logic. 
    services.AddTransient<TestController>(); 

    // Assert 

    var serviceProvider = services.BuildServiceProvider(); 

    var controller = serviceProvider.GetService<TestController>(); 
    Assert.IsNotNull(controller); 
}