Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The API docs for Test::More::ok is

ok($got eq $expected, $test_name);

right now in one of my apps I have $test_name print what the test is testing. So for example in one of my tests I have set this to 'filename exists'. What I realized after I got a bug report recently, and realized that the only time I ever see this message is when the test is failing, if the test is failing that means the file doesn't exist.

In your opinion, do you think these $test_name's should say what the test means if successful? what it means if it failed? or do you think it should say something else? please explain why?

share|improve this question

closed as primarily opinion-based by Ixrec, MichaelT, durron597, gnat, GlenH7 Sep 5 '15 at 13:10

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.

What language / platform is this? I'm not familiar with this syntax. – Marcie Jan 4 '11 at 15:37
@marcie sorry, it's Perl, but this is intended to be generic, and more about what people think would want to see output as a message. Test::More is now a link to perldoc. – xenoterracide Jan 4 '11 at 15:43
up vote 2 down vote accepted

I try to name my tests after the success case (C# syntax below).

public void BeginReviewPopulatesReviewer()
    Distribution = TestData.SubmittedToReviewerDistribution();

If I need to put a specific message to the console, I put the description of the failure:

Assert.IsNotNull(Distribution.CheckWire.Reviewer, "Reviewer is null.");
share|improve this answer
+1 for self-documenting code. – David Jan 4 '11 at 16:24
I would add that the message to be set should probably include the set of parameters that caused that particular failure. It's great to check the logs and spot that a test failed, but much easier if the reason is clearly laid out (although in your test, since it's a binary state, it's not really useful...) – Matthieu M. Jan 4 '11 at 19:54
My goal (not always met!) is to write each test so that there's only one reason for it to fail. – Marcie Jan 4 '11 at 19:55
I think that in Test::More this is really more of Description of failure, than the test name, even though the documentation says otherwise. in other words equivalent to where you put "reviewer is null" – xenoterracide Jan 6 '11 at 6:31
That sounds right to me. – Marcie Jan 6 '11 at 14:18

Following Roy Osherove's guidelines I use the three part naming convention Method_Setup_ExpectedOutcome. This would mean that the test name says what I expect a certain method to behave like under specified outcomes, i.e. the successful outcome of the test.

However, a lot of unit testing frameworks allow you to add additional messages to an assertion. That message will usually be displayed when the assertion fails. In this case I try to word the message to reflect what made this specific assertion fail.

So... for test names I go for the success case, in messages I go for the fail reason.

share|improve this answer
I think that in Test::More this is really more of Description of failure, than the test name, even though the documentation says otherwise. – xenoterracide Jan 5 '11 at 10:51

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