2012-04-20 16 views
8

मैंCollectionAssert.AreEqual में नाकाम रहने के

CollectionAssert.AreEqual(ListExpected, ListActual); 

का उपयोग कर दो सूचियाँ तुलना करने के लिए कोशिश कर रहा हूँ लेकिन मैं एक अपवाद

Expected and actual are both <System.Collections.Generic.List`1[API.Program.Relation]> with 11 elements 
    Values differ at index [0] 
    Expected: <API.Program.Relation> 
    But was: <API.Program.Relation> 

हो रही है लेकिन जब मैं मैदान सब कुछ से मैदान पर Assert.AreEqual का उपयोग कर शून्य तत्व की तुलना में था ठीक।

किसी भी विचार क्यों मैं CollectionAssert

+0

क्या वे वास्तव में बराबर संदर्भित हैं? यहां तक ​​कि यदि सभी डेटा समान हैं, तो यह वही उदाहरण नहीं हो सकता है। – Tejs

+3

उन संग्रहों में से आइटम हैं जिन्हें आप 'बराबर' और 'गेटहाशकोड' को लागू करने की तुलना कर रहे हैं? –

+0

आइटम शून्य के संदर्भ समान थे, या सिर्फ फ़ील्ड मान थे? – ken

उत्तर

11

का उपयोग कर तुलना नहीं कर सकते एक वस्तु "घोषित" है अगर इसकी Equals(object other) विधि सच रिटर्न नेट में किसी अन्य वस्तु के बराबर है। आपको अपने API.Program.Relation कक्षा के लिए उस विधि को लागू करने की आवश्यकता है, अन्यथा .NET आपकी ऑब्जेक्ट को तब तक अलग मानता है जब तक वे संदर्भ-बराबर न हों। तथ्य यह है कि सभी फ़ील्ड समान हैं। .NET से कोई फर्क नहीं पड़ता: यदि आपको क्षेत्र-दर-क्षेत्र समानता अर्थशास्त्र की आवश्यकता है, तो आपको Equals का कार्यान्वयन करने की आवश्यकता है जो इसका समर्थन करता है।

जब आप Equals ओवरराइड करते हैं, तो GetHashCode को ओवरराइड करना न भूलें - इन्हें एक साथ ओवरराइड होना चाहिए।

आप नहीं करना चाहते हैं या किसी कारण से Equals ओवरराइड नहीं कर सकते हैं, तो आप an overload of CollectionAssert.AreEqual कि संग्रह तत्वों की तुलना में सहायता करने के IComparer का एक उदाहरण लेता इस्तेमाल कर सकते हैं।

+3

और जब आप बराबर/गेटहाशकोड ओवरराइड करते हैं, तो कक्षा को अपरिवर्तनीय बनाने पर विचार करें। –

+0

@ हेनकहोल्टरमैन या कम से कम उन फ़ील्ड जिनका उपयोग समानता और हैश कोड की गणना के लिए किया जाता है – phoog

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