Question

I was reading this topic, which is about using reflection to test a private variable…

But I don’t have such problems in my unit test and my code is totally testable.

The only problem is I figured out, it’s very time consuming when doing an assertion for each property of a complex object with an expected result; especially for a list of complex objects.

Since it is a complex object, doing a normal Assert.AreEqual is not going to give me a correct result unless I am implementing IEquality for each of the objects.

But even if I do so, this won’t tell me which property/field’s name, expected value and actual value during assertion.

Correctly, we are manually putting each of the property values into a list and doing a single CollectionAssertion, but this is still time-consuming and when the assertion occurs it only tells me the index of a element value is not equal; it wont’ tell me the property name. Which makes it very difficult to debug (I had to go to debug mode and look at the element in collection).

So I wonder, if I write a recursive reflection method that will do assertion on two complex objects, which will tells me every property name, expected value, actual value.

Is that a good practice or bad practice?

Answer 1

IMHO, it is a bad practice because:

• Reflection code is slow and difficult to write right
• It is even more difficult to maintain and such code may not be refactor-friendly
• Reflection is slow, unit tests shall be fast
• _{It also doesn’t feel right}

To me this looks as if you are trying to plug a hole, rather than fix a problem. In order to fix the problem I can suggest to segregate a large and complex class into a set of smaller ones. If you have many properties – group them into individual classes

---

So that such class

class Foo
{
    T1 Prop1 {get; set;}
    T2 Prop2 {get; set;}
    T3 Prop3 {get; set;}
    T4 Prop4 {get; set;}
}

Would become

class Foo
{
    T12 Prop12 {get; set;}  
    T34 Prop34 {get; set;}  
}
class T12
{
    T1 Prop1 {get; set;}
    T2 Prop2 {get; set;}
}
class T34
{
    T3 Prop3 {get; set;}
    T4 Prop4 {get; set;}
}

Note, that the Foo has now got only one property (that is a “grouped” representation). If you can group the properties in a way, so that any state change would be localised to a specific group – your task becomes much more simplified. You can then assert that a “grouped” property is equal to the expected state.