Naming tests, once again

I’m coming across a lot of tests with names like this:

AddEmployee_Should_Pass_When_Not_Duplicate() {…..}

AddEmployee_Should_Fail_When_Duplicate() {….}

For the purpose of this post, I don’t care about anything other than what’s in bold and red.

The word Pass in there is completely irrelevant and useless. The word Fail is just mind-blowing. What should fail? The test? What if the test passes? Does that mean it has really failed? Or when it fails it means it passes?

Now we all know what Fail means here. It means the test will pass but the call will fail. But it doesn’t indicate to us what failure consists of and therefore it’s not adding information. Someone looking at the test cannot validate it.

When naming, indicate what the test is trying to validate, not what the outcome is; the outcome is already known: pass or failure.

Something along the lines of Add_Employee_Should_Throw_Exception_When_Employee_Already_Exists would add substantial information for the person reading your test to validate the functionality. But more importantly, when the test fails, they would know what has failed and have valuable information for debugging. 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s