C # में यूनिट परीक्षण निजी तरीके

Question

विजुअल स्टूडियो स्वचालित रूप से उत्पन्न एक्सेसर क्लास के माध्यम से निजी तरीकों के यूनिट परीक्षण की अनुमति देता है। मैंने एक निजी पद्धति का एक परीक्षण लिखा है जो सफलतापूर्वक संकलित करता है, लेकिन यह रनटाइम में विफल रहता है। कोड और परीक्षण का एक काफी न्यूनतम संस्करण है:

//in project MyProj
class TypeA
{
    private List<TypeB> myList = new List<TypeB>();

    private class TypeB
    {
        public TypeB()
        {
        }
    }

    public TypeA()
    {
    }

    private void MyFunc()
    {
        //processing of myList that changes state of instance
    }
}    

//in project TestMyProj           
public void MyFuncTest()
{
    TypeA_Accessor target = new TypeA_Accessor();
    //following line is the one that throws exception
    target.myList.Add(new TypeA_Accessor.TypeB());
    target.MyFunc();

    //check changed state of target
}

रनटाइम त्रुटि है:

Object of type System.Collections.Generic.List`1[MyProj.TypeA.TypeA_Accessor+TypeB]' cannot be converted to type 'System.Collections.Generic.List`1[MyProj.TypeA.TypeA+TypeB]'.

Intellisense के अनुसार - और इसलिए मुझे लगता है कि कंपाइलर - टारगेट TypeA_Accessor का है। लेकिन रनटाइम में यह टाइपो का होता है, और इसलिए सूची जोड़ने में विफल रहता है।

क्या इस त्रुटि को रोकने का कोई तरीका है? या, शायद अधिक संभावना है, अन्य लोगों के पास क्या सलाह है (मुझे लगता है कि शायद "निजी तरीकों का परीक्षण न करें" और "यूनिट परीक्षण नहीं है वस्तुओं की स्थिति में हेरफेर")।

Comments

आपको निजी वर्ग TypeB के लिए एक एक्सेसर की आवश्यकता है। Accessor TypeA_Accessor निजी और TypeA के संरक्षित तरीकों तक पहुँच प्रदान करता है। हालाँकि TypeB एक विधि नहीं है। यह एक वर्ग है।

— दिमा

एक्सेसर निजी / संरक्षित विधियों, सदस्यों, गुणों और घटनाओं तक पहुंच प्रदान करता है। यह आपकी कक्षा के भीतर निजी / संरक्षित कक्षाओं तक पहुँच प्रदान नहीं करता है। और निजी / संरक्षित वर्गों (टाइपबी) का उपयोग केवल मालिक वर्ग (टाइपा) के तरीकों से किया जाता है। इसलिए मूल रूप से आप TypeA के बाहर से निजी वर्ग (TypeB) को "myList" में जोड़ने का प्रयास कर रहे हैं जो कि निजी है। चूंकि आप एक्सेसर का उपयोग कर रहे हैं, इसलिए myList तक पहुंचने के लिए कोई समस्या नहीं है। हालाँकि आप Accessor के माध्यम से TypeB का उपयोग नहीं कर सकते हैं। पॉसिबल समाधान TypeA के बाहर टाइपबी को स्थानांतरित करने के लिए होगा। लेकिन यह आपके डिजाइन को तोड़ सकता है।

— दीमा

महसूस करें कि निजी तरीकों का परीक्षण निम्नलिखित stackoverflow.com/questions/250692/…

— nate_weldon

Answer 1

हां, निजी विधियों का परीक्षण न करें .... इकाई परीक्षण का विचार इकाई को उसके सार्वजनिक 'एपीआई' द्वारा जांचना है।

यदि आप पा रहे हैं कि आपको बहुत सारे निजी व्यवहार का परीक्षण करने की आवश्यकता है, तो सबसे अधिक संभावना है कि आपके पास एक नया 'वर्ग' है जो उस वर्ग के भीतर छिपा है जिसे आप परीक्षण कर रहे हैं, इसे निकालें और इसके सार्वजनिक इंटरफ़ेस द्वारा परीक्षण करें।

सलाह / सोचने के उपकरण का एक टुकड़ा ..... एक विचार है कि कोई भी तरीका कभी भी निजी नहीं होना चाहिए। मतलब सभी तरीकों को एक वस्तु के सार्वजनिक इंटरफ़ेस पर रहना चाहिए .... अगर आपको लगता है कि आपको इसे निजी बनाने की आवश्यकता है, तो यह संभवतः किसी अन्य ऑब्जेक्ट पर रहता है।

सलाह का यह टुकड़ा व्यवहार में काफी काम नहीं करता है, लेकिन इसकी ज्यादातर अच्छी सलाह है, और अक्सर यह लोगों को अपनी वस्तुओं को छोटी वस्तुओं में विघटित करने के लिए प्रेरित करेगा।

Comments

मैं असहमत हूं। OOD में, निजी तरीके और गुण अपने आप को नहीं दोहराने के लिए एक आंतरिक तरीका है ( en.wikipedia.org/wiki/Don%27t_repeat_yourself )। ब्लैक बॉक्स प्रोग्रामिंग और इनकैप्सुलेशन के पीछे का विचार सब्सक्राइबर से तकनीकी विवरण को छिपाना है। इसलिए आपके कोड में गैर-तुच्छ निजी तरीकों और गुणों का होना आवश्यक है। और अगर यह गैर-तुच्छ है, तो इसे जांचने की आवश्यकता है।

— एक्सडी

इसकी आंतरिक नहीं, कुछ ओओ भाषाओं में निजी विधियां नहीं हैं, निजी संपत्तियों में सार्वजनिक इंटरफेस वाली वस्तुएं हो सकती हैं जिन्हें परीक्षण किया जा सकता है।

— कीथ निकोलस

इस सलाह की बात यह है कि यदि आप अपनी वस्तु को एक काम करते हैं, और डीआरवाई करते हैं, तो निजी तरीकों के लिए अक्सर बहुत कम कारण होते हैं। अक्सर निजी तरीके कुछ ऐसा करते हैं जो वस्तु वास्तव में ज़िम्मेदार नहीं है, लेकिन यह बहुत उपयोगी है, यदि गैर तुच्छ है, तो यह आम तौर पर एसआरपी का उल्लंघन करने की संभावना के रूप में एक और वस्तु है

— कीथ निकोलस

गलत। आप कोड डुप्लीकेशन से बचने के लिए निजी तरीकों का उपयोग करना चाह सकते हैं। या मान्यता के लिए। या कई अन्य उद्देश्यों के लिए जिनके बारे में सार्वजनिक दुनिया को पता नहीं होना चाहिए।

— जोर्ज

जब आपको एक OO कोडबेस पर डंप किया गया है तो बहुत ही भयानक तरीके से डिज़ाइन किया गया है और "incrementally improve it it" के लिए कहा गया है, यह एक निराशा थी कि मैं निजी तरीकों के लिए कुछ पहले परीक्षण नहीं कर पाया। हाँ, शायद पाठ्यपुस्तकों में ये विधियाँ यहाँ नहीं होंगी, लेकिन वास्तविक दुनिया में हमारे पास ऐसे उपयोगकर्ता हैं जिनकी उत्पाद आवश्यकताएँ हैं। मैं बस निर्माण करने के लिए परियोजना में कुछ परीक्षण प्राप्त किए बिना एक बड़े पैमाने पर "मा क्लीन कोड पर नज़र" रिफैक्टिंग नहीं कर सकता। प्रोग्रामर को अभ्यास करने के लिए मजबूर करने के एक और उदाहरण की तरह महसूस करता है जो भोलेपन से अच्छा लगता है, लेकिन असली गड़बड़ गंदगी का हिसाब लेने में विफल रहता है।

— dune.rocks

Answer 2

आप PrivateObject क्लास का उपयोग कर सकते हैं

Class target = new Class();
PrivateObject obj = new PrivateObject(target);
var retVal = obj.Invoke("PrivateMethod");
Assert.AreEqual(expectedVal, retVal);

Comments

यह सही उत्तर है, अब जब Microsoft ने PrivateObject जोड़ा है।

— ज़ोइ

अच्छा जवाब लेकिन कृपया ध्यान दें कि PrivateMethod को "निजी" के बजाय "संरक्षित" होना चाहिए।

— हर्बलमार्ट

@HerbalMart: शायद मैं आपको गलत समझ रहा हूं, लेकिन अगर आप सुझाव दे रहे हैं कि PrivateObject केवल संरक्षित सदस्यों तक पहुंच सकता है और निजी लोगों से नहीं, तो आप गलत हैं।

— किमी

@JeffPearce स्थिर तरीकों के लिए आप "PrivateType pt = new PrivateType (typeof (Myassass));" का उपयोग कर सकते हैं, और फिर pt ऑब्जेक्ट पर InvokeStatic को कॉल कर सकते हैं क्योंकि आप किसी निजी ऑब्जेक्ट पर Invoke को कॉल करेंगे।

— स्टीव हिबर्ट

यदि कोई MSTest.TestFramework v1.2.1 के रूप में सोच रहा था - PrivateObject और PrivateType कक्षाएं .NET कोर 2.0 को लक्षित करने वाली परियोजनाओं के लिए अनुपलब्ध हैं - इसके लिए एक github मुद्दा है: github.com/Microsoft/estestfx/issues/366

— shiitake

Answer 3

"मानक या सर्वोत्तम अभ्यास के रूप में कुछ भी नहीं कहा जाता है, शायद वे सिर्फ लोकप्रिय राय हैं"।

इस चर्चा के लिए भी यही सच है।

यह सब इस बात पर निर्भर करता है कि आप क्या सोचते हैं कि यह एक इकाई है, यदि आपको लगता है कि यूएनआईटी एक वर्ग है तो आप केवल सार्वजनिक पद्धति से टकराएंगे। अगर आपको लगता है कि UNIT निजी तरीकों से कोड मारने की रेखा है, तो आपको दोषी महसूस नहीं होगा।

यदि आप निजी विधियों को लागू करना चाहते हैं, तो आप "PrivateObject" वर्ग का उपयोग कर सकते हैं और आह्वान विधि को कॉल कर सकते हैं। आप इस indepth youtube वीडियो ( http://www.youtube.com/watch?v=Vq6Gcs9LrPQ ) को देख सकते हैं जो दिखाता है कि "PrivateObject" का उपयोग कैसे किया जाता है और यह भी चर्चा करता है कि निजी तरीकों का परीक्षण तार्किक है या नहीं।

Answer 4

एक अन्य विचार यहाँ "आंतरिक" कक्षाओं / विधियों में परीक्षण का विस्तार करना है, इस परीक्षण के एक सफ़ेद-बॉक्स की अधिक समझ दे रहा है। आप यूनिट परीक्षण मॉड्यूल को अलग करने के लिए इनका खुलासा करने के लिए असेंबली पर इंटरवल वैजटेरऑटवर्ट का उपयोग कर सकते हैं।

सीलबंद वर्ग के संयोजन में आप इस तरह के इनकैप्सुलेशन से संपर्क कर सकते हैं कि टेस्ट विधि आपके तरीकों को केवल असेंबली असेंबली से दिखाई देती है। विचार करें कि सीलबंद वर्ग में संरक्षित विधि वास्तव में निजी है।

[assembly: InternalsVisibleTo("MyCode.UnitTests")]
namespace MyCode.MyWatch
{
    #pragma warning disable CS0628 //invalid because of InternalsVisibleTo
    public sealed class MyWatch
    {
        Func<DateTime> _getNow = delegate () { return DateTime.Now; };


       //construktor for testing purposes where you "can change DateTime.Now"
       internal protected MyWatch(Func<DateTime> getNow)
       {
           _getNow = getNow;
       }

       public MyWatch()
       {            
       }
   }
}

और इकाई परीक्षण:

namespace MyCode.UnitTests
{

[TestMethod]
public void TestminuteChanged()
{
    //watch for traviling in time
    DateTime baseTime = DateTime.Now;
    DateTime nowforTesting = baseTime;
    Func<DateTime> _getNowForTesting = delegate () { return nowforTesting; };

    MyWatch myWatch= new MyWatch(_getNowForTesting );
    nowforTesting = baseTime.AddMinute(1); //skip minute
    //TODO check myWatch
}

[TestMethod]
public void TestStabilityOnFebruary29()
{
    Func<DateTime> _getNowForTesting = delegate () { return new DateTime(2024, 2, 29); };
    MyWatch myWatch= new MyWatch(_getNowForTesting );
    //component does not crash in overlap year
}
}

Comments

मुझे यकीन नहीं कि मैं समझा हूँ। InternalsV अदृश्यToAttribute "आंतरिक" सुलभ के रूप में चिह्नित किए गए तरीकों और विशेषताओं को बनाता है, लेकिन मेरे क्षेत्र और विधियां "निजी" हैं। क्या आप सुझाव दे रहे हैं कि मैं निजी से आंतरिक में चीजों को बदलूं? मुझे लगता है कि मैं गलत समझ रहा हूं।

— junichiro

हां, मैं यही सुझाव दे रहा हूं। यह थोड़ा "हैकी" है, लेकिन कम से कम वे "सार्वजनिक" नहीं हैं।

— जेफ

यह एक अद्भुत जवाब है , क्योंकि यह नहीं कहता है कि "निजी तरीकों का परीक्षण न करें" लेकिन हां, यह काफी "हैकी" है। काश कोई उपाय होता। IMO यह कहना बुरा है कि "निजी तरीकों का परीक्षण नहीं किया जाना चाहिए" क्योंकि मैं इसे जिस तरह से देखता हूं : यह "निजी तरीकों के लिए सही नहीं होना चाहिए" के बराबर है।

— मास्टरमैस्ट

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

— mr.Pony

मैं MasterMastic से सहमत हूँ। यह स्वीकृत उत्तर होना चाहिए।

— XDS

Answer 5

निजी तरीकों का परीक्षण करने का एक तरीका प्रतिबिंब के माध्यम से है। यह NUnit और XUnit पर भी लागू होता है:

MyObject objUnderTest = new MyObject();
MethodInfo methodInfo = typeof(MyObject).GetMethod("SomePrivateMethod", BindingFlags.NonPublic | BindingFlags.Instance);
object[] parameters = {"parameters here"};
methodInfo.Invoke(objUnderTest, parameters);

Comments

call methods स्थिर और गैर स्थिर ?

— किनिकेत

प्रतिबिंब-निर्भर तरीकों का नकारात्मक पक्ष यह है कि जब आप R # का उपयोग करके विधियों का नाम बदलते हैं तो वे टूट जाते हैं। यह छोटी परियोजनाओं पर एक बड़ी समस्या नहीं हो सकती है, लेकिन विशाल कोड-बेस पर यह इस तरह से इकाई परीक्षणों को इस तरह से तोड़ना और फिर उन्हें जल्दी से जल्दी ठीक करना और ठीक करना है। इस लिहाज से मैं अपना पैसा जेफ के जवाब पर जाता हूं।

— XDS

@XDS बहुत बुरा नाम () अपनी कक्षा के बाहर से एक निजी विधि का नाम लेने के लिए काम नहीं करता है।

— गैब्रियल मॉरिन

Answer 6

एर्म ... बिल्कुल एक ही समस्या के साथ यहां आया था: एक सरल , लेकिन निजी निजी विधि का परीक्षण करें । इस धागे को पढ़ने के बाद, ऐसा प्रतीत होता है कि "मैं इस साधारण टुकड़े को धातु के इस साधारण छेद में ड्रिल करना चाहता हूं, और मैं यह सुनिश्चित करना चाहता हूं कि गुणवत्ता चश्मा से मिलती है", और फिर "ठीक है, यह आसान नहीं है।" सबसे पहले, वहाँ ऐसा करने का कोई उचित उपकरण है, लेकिन आप अपने बगीचे में एक गुरुत्वाकर्षण तरंग वेधशाला का निर्माण कर सकता है। पर मेरे लेख पढ़ें http://foobar.brigther-than-einstein.org/ सबसे पहले, निश्चित रूप से, आप कुछ उन्नत क्वांटम भौतिकी पाठ्यक्रमों में भाग लेना है, तो आपको अल्ट्रा-कूल नाइट्रोजन के टन की आवश्यकता है, और फिर, निश्चित रूप से, मेरी पुस्तक अमेज़ॅन पर उपलब्ध है "...

दूसरे शब्दों में...

नहीं, पहली चीजें पहले।

प्रत्येक और हर विधि, निजी, आंतरिक, संरक्षित, सार्वजनिक हो सकती है परीक्षण योग्य होने के लिए। इस तरह के विशेषण के बिना इस तरह के परीक्षणों को लागू करने का एक तरीका होना चाहिए जैसा कि यहां प्रस्तुत किया गया था।

क्यों? बिल्कुल इसलिए क्योंकि कुछ योगदानकर्ताओं द्वारा अब तक किए गए वास्तुशिल्प उल्लेखों के । शायद सॉफ्टवेयर सिद्धांतों का एक सरल पुनर्लेखन कुछ गलतफहमियों को दूर कर सकता है।

इस मामले में, सामान्य संदिग्ध हैं: ओसीपी, एसआरपी और, हमेशा की तरह, केआईएस।

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

मैं किस बारे में बात कर रहा हूं?

निजी डबल ट्रांस्लेशन

कुंभ राशि या जिसे आजकल कहा जाता है, की घोषणा करना आसान है, लेकिन अगर मेरे सेंसर का टुकड़ा 1.0 से 2.0 तक हो जाता है, तो अनुवाद का कार्यान्वयन ... एक सरल रेखीय समीकरण से बदल सकता है जो आसानी से समझ में आता है और "पुनः-" प्रयोग करने योग्य "हर किसी के लिए, एक बहुत परिष्कृत गणना के लिए जो विश्लेषण या जो कुछ भी उपयोग करता है, और इसलिए मैं अन्य कोड को तोड़ दूंगा। क्यों? क्योंकि वे सॉफ्टवेयर कोडिंग के बहुत सारे उदाहरणों को नहीं समझते थे, यहां तक ​​कि KIS को भी नहीं।

इस परियों की कहानी को छोटा करने के लिए: हमें निजी तरीकों का परीक्षण करने के लिए एक सरल तरीका चाहिए - बिना विज्ञापन के।

पहला: सभी को नया साल मुबारक हो!

दूसरा: अपने वास्तुकार के पाठों का पूर्वाभ्यास करें।

तीसरा: "सार्वजनिक" संशोधक धर्म है, समाधान नहीं।

Answer 7

एक अन्य विकल्प जिसका उल्लेख नहीं किया गया है, बस यूनिट टेस्ट क्लास को उस ऑब्जेक्ट के बच्चे के रूप में बना रहा है जिसे आप परीक्षण कर रहे हैं। NUnit उदाहरण:

[TestFixture]
public class UnitTests : ObjectWithPrivateMethods
{
    [Test]
    public void TestSomeProtectedMethod()
    {
        Assert.IsTrue(this.SomeProtectedMethod() == true, "Failed test, result false");
    }
}

यह निजी और संरक्षित (लेकिन विरासत में मिली निजी) विधियों का आसान परीक्षण करने की अनुमति देगा, और यह आपको अपने सभी परीक्षणों को वास्तविक कोड से अलग रखने की अनुमति देगा ताकि आप उत्पादन के लिए परीक्षण असेंबलियों को तैनात नहीं कर रहे हैं। अपने निजी तरीकों को संरक्षित विधियों में बदलना विरासत में मिली कई वस्तुओं में स्वीकार्य होगा, और यह एक बहुत ही सरल बदलाव है।

तथापि...

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

जब मैं इस दृष्टिकोण का उल्लेख करता हूं, तो मैं सुझाव दूंगा कि यह एक वैध समाधान की तुलना में मंथन का अधिक सुझाव है। नमक के साथ ले।

संपादित करें: मुझे यह वास्तव में प्रफुल्लित करने वाला लगता है कि लोग इस उत्तर को वोट कर रहे हैं, क्योंकि मैं स्पष्ट रूप से इसे एक बुरे विचार के रूप में वर्णित करता हूं। क्या इसका मतलब यह है कि लोग मुझसे सहमत हैं? मैं बहुत उलझा हुआ हूं.....

Comments

यह एक रचनात्मक समाधान है लेकिन थोड़े हैकी है।

— शिंज़ौ

Answer 8

विरासत कोड के साथ प्रभावी ढंग से काम कर रही पुस्तक से :

"अगर हमें एक निजी पद्धति का परीक्षण करने की आवश्यकता है, तो हमें इसे सार्वजनिक करना चाहिए। यदि इसे सार्वजनिक करने से हमें परेशान होता है, तो ज्यादातर मामलों में, इसका मतलब है कि हमारी कक्षा बहुत अधिक कर रही है और हमें इसे ठीक करना चाहिए।"

लेखक के अनुसार, इसे ठीक करने का तरीका एक नया वर्ग बनाकर और विधि को जोड़कर है public ।

लेखक आगे बताते हैं:

"अच्छा डिजाइन परीक्षण योग्य है, और जो डिजाइन परीक्षण योग्य नहीं है वह खराब है।"

तो, इन सीमाओं के भीतर, आपका एकमात्र वास्तविक विकल्प विधि बनाना है public, या तो वर्तमान या एक नए वर्ग में।

Answer 9

टीएल; डीआर: निजी कक्षा को दूसरी कक्षा में निकालें, उस कक्षा पर परीक्षण करें; SRP सिद्धांत (एकल जिम्मेदारी सिद्धांत) के बारे में अधिक पढ़ें

ऐसा लगता है कि आपको privateकिसी अन्य वर्ग के लिए विधि निकालने की आवश्यकता है ; इसमें होना चाहिए public। privateविधि पर परीक्षण करने की कोशिश करने के बजाय , आपको publicइस अन्य वर्ग की विधि का परीक्षण करना चाहिए ।

हमारे पास निम्न परिदृश्य है:

Class A
+ outputFile: Stream
- _someLogic(arg1, arg2) 

हमें के तर्क का परीक्षण करने की आवश्यकता है _someLogic; लेकिन ऐसा लगता है कि Class Aइसकी आवश्यकता से अधिक भूमिका (एसआरपी सिद्धांत का उल्लंघन); सिर्फ दो वर्गों में परावर्तक

Class A1
    + A1(logicHandler: A2) # take A2 for handle logic
    + outputFile: Stream
Class A2
    + someLogic(arg1, arg2) 

इस तरह someLogicA2 पर परीक्षण किया जा सकता है; A1 में सिर्फ कुछ नकली A2 बनाएं फिर निर्माणकर्ता को यह परीक्षण करने के लिए इंजेक्ट करें कि A2 को फ़ंक्शन नाम दिया गया है someLogic।

Answer 10

वीएस 2005/2008 में आप निजी सदस्य का परीक्षण करने के लिए निजी एक्सेसर का उपयोग कर सकते हैं , लेकिन वीएस के बाद के संस्करण में यह तरीका गायब हो गया था

Comments

2008 से शायद 2010 की शुरुआत तक अच्छा जवाब। अब कृपया PrivateObject और प्रतिबिंब विकल्प को देखें (ऊपर कई उत्तर देखें)। VS2010 में एक्सेसर बग (ओं) थे, MS ने इसे VS2012 में चित्रित किया। जब तक आप वीएस2010 या पुराने (> 18 वर्ष पुराने टूल टूलिंग) में रहने के लिए मजबूर नहीं होते हैं, कृपया निजी एक्सेसरों से बचकर अपना समय बचाएं। :-)।

— ज़ेफन श्रोएडर