2012-08-14 13 views
6

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

[Theory] 
[Dependency] 
public void TestWithDependencies(IThing thing) 
{ 
    thing.Hello(); 
} 

ऐसा करने के लिए मैं निम्न कर सकते हैं:

मैं क्या करना चाहते हैं क्या परीक्षण है कि कुछ इस तरह दिखाई है

public sealed class DependencyAttribute : AutoDataAttribute 
{ 
    public DependencyAttribute() 
     : base(new Fixture().Customize(new WindsorCustomization())) 
    { 
    } 
} 

public class WindsorCustomization : ICustomization 
{ 
    public WindsorCustomization() 
    { 
     // build container here using SUT installers 
    } 

    public void Customize(IFixture fixture) 
    { 
     fixture.Inject<IThing>(new Thing()); 
    } 
} 

ऐसा काम करता है, लेकिन मैं जो टालना चाहता हूं उसे ऑटोफिक्स्चर IFixture में विंडसर कंटेनर से कार्यान्वयन मैपिंग में प्रत्येक इंटरफ़ेस की प्रतिलिपि बनाने की आवश्यकता है।

+0

Welp! मैंने ऑटोमोक के लिए कोड पर एक नज़र डाली और देखा कि मैं क्या करना चाहता हूं। यदि कोई दिलचस्पी लेता है तो मैं कोड को उत्तर में पोस्ट कर सकता हूं। – thebeekeeper

+0

हां, यह ऑटोमोक कैसे काम करता है इसके करीब है :) –

उत्तर

6

आप इस तरह कुछ करने के लिए सक्षम होना चाहिए:

public class WindsorCustomization : ICustomization 
{ 
    private readonly IWindsorContainer container; 

    public WindsorCustomization() 
    { 
     // build this.container here using SUT installers 
    } 

    public void Customize(IFixture fixture) 
    { 
     fixture.Customizations.Add(new WindsorAdapter(this.container)); 
    } 
} 

public WindsorAdapter : ISpecimenBuilder 
{ 
    private readonly IWindsorContainer container; 

    public WindsorAdapter(IWindsorContainer container) 
    { 
     this.container = container; 
    } 

    public object Create(object request, ISpecimenContext context) 
    { 
     var t = request as Type; 
     if (t == null || !this.container.Kernel.HasComponent(t)) 
      return new NoSpecimen(request); 

     return this.container.Resolve(t);     
    } 
} 

WindsorAdapter Customizations संग्रह है, जो काफी जिम्मेदारी का AutoFixture के पेड़ के शुरू में है में बैठता है, तो यह हर संभाल करने के लिए एक मौका हो जाता है (या सबसे) आने वाले अनुरोध। अगर अनुरोध एक प्रकार का उदाहरण है और विंडसर कोंटेनर के उस प्रकार के लिए एक घटक है, तो एडाप्टर कंटेनर को प्रकार को हल करने के काम को दर्शाता है।

अन्यथा, यह NoSpecimen उदाहरण देता है, जो मूल रूप से स्वत: मिश्रण का संकेत है कि यह विशेष ISpecimenBuilder अनुरोध को संभाल नहीं सकता है। ऑटोफिक्चर में कुछ अन्य घटक जिम्मेदारी के वृक्ष को अनुरोध को संभालने का मौका मिलता है।

+1

हाँ, यह वही है जो मैंने किया था। इसके बारे में रोमांचक हिस्सा यह है कि चूंकि मैं कोड का परीक्षण कर रहा हूं जो केवल 1/3 लागू है, मैं उस कोड के लिए खड़े होने के लिए ऑटोमोक का उपयोग करने में सक्षम होना चाहिए जो मौजूद नहीं है और अभी भी मौजूद कोड का परीक्षण कर सकता है। महान पुस्तकालय! – thebeekeeper

+0

हां, आपको बस यह सुनिश्चित करने की आवश्यकता है कि ऑटोमोक कस्टमाइज़ेशन आखिरी/बाद में आता है: http://blog.ploeh.dk/2012/07/31/TheOrderOfAutoFixtureCustomizationsMatter.aspx –

संबंधित मुद्दे