(this mini-post is part of a series about good testing practices)

Another problem that makes it more difficult to understand tests is unclear language.

Two guidelines that help me deal with this:

  1. We want to use decisive language
  2. We want the language to be specific and explicit

Suppose we have a book store and we’re testing the functionality for editing a book.
Let’s see some examples of test phrasing:

def test_edit_book(): ...

This is simply too general.
There are so many things that might be tested, and this means almost nothing about what will get tested in practice.

def test_edit_book_works_correctly(): ...

Adding things like “it works” or “it’s correct” - most of the time, this is just bloat.
It only makes the name bigger, but doesn’t give us any extra information.

def test_user_should_be_able_to_edit_their_own_book(): ...

That’s much better - it’s a lot more specific.
The only problem here is the indecisive language.

Why “should”?
Will this ever NOT be correct?

It’s both bloated and confusing.
So this as well - not optimal.

def test_user_can_edit_their_own_book(): ...

That’s much better in my opinion.
It’s decisive, explicit and specific.
I suggest to aim towards this whenever possible.

Conclusion

When phrasing test names and descriptions, try to aim for decisive, specific and explicit language.

<< previous post: No Locality of Behavior | next post: Testing Too Many Things >>