Given that a method's name might change in time, is it a good idea to specify the name of the method whose return value I am asserting as a part of the Unit Test method's name? What about the message that will be output to the caller?

For example, I have a Foo object that has a Bar method. I would like to assert if Bar returns true in some specific conditions. I write such a Unit Test:

public void Bar_ReturnsTrue_Always()
    // the logic of the method goes here

    Assert.IsTrue(Foo.Bar(), "Return value of Bar was different then: true"

It seems pretty ugly to me, because the name Bar may change in the future, for example to Blargh. If this happens, there is a possibility that the developer will forget to change relevant information in one or both places where it's necessary (method's name and the message). On the other hand, how is the caller supposed to know what is being tested if such information isn't publicly present? I can't think of a good enough solution to this. Any ideas?

closed as primarily opinion-based by durron597, gnat, user40980, Kilian Foth, user22815 Aug 3 '15 at 14:28

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Why does the caller need to know? The only time they care is when it fails, and at that point it is painfully obvious what method is being called. – Telastyn Oct 17 '14 at 15:21

It's not generally needed. As @Telastyn says, if the test case fails, then it will become quickly and readily apparent what method failed.

The real need is to have the purpose of your test easily understood by those that

  1. are adding, reviewing, or modifying tests after you (even if that person is also you), and
  2. are reviewing the code and searching for causes if/when the test fails.

It's not bad practice, per se, to name the method in either the test case/function, or in the error message. If it's easy to do and feels appropriate--as it does in your example--feel free. If the test is "Bar() should return true" then Bar_Always_True is reasonable. On the other hand, if your method is AddInt and you're testing A + B == B + A, Addition_Is_Commutative might make more sense than a test case name that insists on including AddInt in the name. This "state your intention rather than your method name" principle becomes ever more important as test cases become more complex, potentially involving more than one method.

  • Additional point: You probably don't need the error message in the assertion. Many consider that an anti-pattern / worst practice. If the assertion fails, any developer looking at the code will quickly see why. Don't waste your time crafting error messages for tests when the failing condition will quickly be apparent. – Jonathan Eunice Oct 17 '14 at 16:00
  • Thanks for this answer. It's not a black or white situation, it seems. But the light you shed on this matter is very valuable to me. – Kapol Oct 17 '14 at 20:17

No, you do not need to add messages to most assertions. Writing unit tests as you suggest would be needlessly tedious. Presumably the Assert.IsTrue method will throw an exception saying something like "Expected true, got false". The ensuing stack trace will pinpoint the cause of the failure.

N.B. In general, as a programmer, you should not be spending time writing obvious and repetitive code. If you are, then it is likely you misunderstand the library you are using, or else there is some library that will simplify the work. If you feel that your work could be done by a trained monkey, something is wrong.

Not the answer you're looking for? Browse other questions tagged or ask your own question.