Home/ Questions/Q 6335237
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T18:49:00+00:00

I have read in several book and articles about TDD and BDD that one

  • 0

I have read in several book and articles about TDD and BDD that one should avoid multiple assertions or expectations in a single unit test or specification. And I can understand the reasons for doing so. Still I am not sure what would be a good way to verify a complex result.

Assuming a method under test returns a complex object as a result (e.g. deserialization or database read) how do I verify the result correctly?

1.Asserting on each property:

  Assert.AreEqual(result.Property1, 1);
  Assert.AreEqual(result.Property2, "2");
  Assert.AreEqual(result.Property3, null);
  Assert.AreEqual(result.Property4, 4.0);

2.Relying on a correctly implemented .Equals():

Assert.AreEqual(result, expectedResult);

The disadvantage of 1. is that if the first assert fails all the following asserts are not run, which might have contained valuable information to find the problem. Maintainability might also be a problem as Properties come and go.

The disatvantage of 2. is that I seem to be testing more than one thing with this test. I might get false positives or negatives if .Equals() is not implemented correctly. Also with 2. I do not see, what properties are actually different if the test fails but I assume that can often be addressed with a decent .ToString() override. In any case I think I should avoid to be forced to throw the debugger at the failing tests to see the difference. I should see it right away.

The next problem with 2. is that it compares the whole object even though for some tests only some properties might be significant.

What would be a decent way or best practise for this in TDD and BDD.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    With the context present in the question I’d go for option 1.

    It likely depends on context. If I’m using some sort of built in object serialization within the .NET framework, I can be reasonably assured that if no errors were encountered then the entire object was appropriately marshaled. In that case, asserting a single field in the object is probably fine. I trust MS libraries to do the right thing.

    If you are using SQL and manually mapping results to domain objects I feel that option 1 makes it quicker to diagnose when something breaks than option 2. Option 2 likely relies on toString methods in order to render the assertion failure:

    Expected <1 2 null 4.0> but was <1 2 null null>

    Now I am stuck trying to figure out what field 4.0/null was. Of course I could put the field name into the method:

    Expected <Property1: 1, Property2: 2, Property3: null, Property4: 4.0>
 but was <Property1: 1, Property2: 2, Property3: null, Property4: null>

    This is fine for small numbers of properties, but begins to break down larger numbers of properties due to wrapping, etc. Also, the toString maintenance could become an issue as it needs to change at the same rate as the equals method.

    Of course there is no correct answer, at the end of the day, it really boils down to your team’s (or your own) personal preference.

    Hope that helps!

    Brandon

    • 0