Home/ Questions/Q 823675
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T02:59:05+00:00

When writing unit tests, there are cases where one can create an Assert for

  • 0

When writing unit tests, there are cases where one can create an Assert for each condition that could fail or an Assert that would catch all such conditions. C# Example:

Dictionary<string, string> dict = LoadDictionary();
// Optional Asserts:
Assert.IsNotNull(dict, "LoadDictionary() returned null");
Assert.IsTrue(dict.Count > 0, "Dictionary is empty");
Assert.IsTrue(dict.ContainsKey("ExpectedKey"), "'ExpectedKey' not in dictionary");
// Condition actually interested in testing:
Assert.IsTrue(dict["ExpectedKey"] == "ExpectedValue", "'ExpectedKey' is present but value is not 'ExpectedValue'");

Is there value to a large, multi-person project in this kind of situation to add the “Optional Asserts”? There’s more work involved (if you have lots of unit tests) but it will be more immediately clear where the problem lies.

I’m using VS 2010 and the integrated testing tools but intend the question to be generic.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think that there is a value in doing something like this but you have to be carefuly how to use it. I also work on a large, multi-person project, and recently we have started to use similar approach in our unit testing strategy.

    We try to have one test per “execution path”, and we have test cases with multiple asserts. However, we use fatal and non-fatal asserts in our test cases, and only non-fatal asserts are used in those test cases that have multiple asserts. Fatal asserts are also used in these test cases (one per TC) to validate condition which if fails there is no point in asserting anything else. This approach helps us to faster localize errors as sometimes more than one assert can occur.

    Combining it with custom logs to provide additional information on failures – testing and debugging is much faster and actually more efficient.

    However, looking at your example, I am not sure if “multiple/optional asserts” is really good aproach as most likely you do not want to test these basic functionalities over and over again (LoadDict(), not empty etc). I think that in your case, the “test case setup” should ensure that Dictionary is “not empty” and LoadDictionary() performs as expected (already tested with specific TCs). The goal of this test case seems to be validating the lookup method and it should be focused on testing that thing only. Everything else is setup/other functinality and should not belong to this TC, really.

    • 0