Giving names to unit tests

testing
ex_unit

#1

Hello people! Just wanted to bring a discussion to the community that happened on my team.

When it comes to testing, naming the tests is itself an art. There are several approaches and all of them and none of them are right/wrong. I’ve seen several patterns through the community and some others on my team because of the different backgrounds each have on the subject. I’d like to know your opinions about it.

Different styles

Here is some styles I’ve seen:

  • The AAA approach (arrange - act - assert): gives names like test "given a proper user when it authenticates it receives a proper session"
  • The “it does some result” approach: test "it authenticates properly"
  • The “it capabilities” approach: test "it can authenticate an active user"
  • The “result verb” approach: test "succeeds authentication with an active user"
  • The “action” approach: test "authenticates an active user"

So on …

Describe and trace option

What gives me some anxiety is the way the sentence ends up when we use “describe” and the “–trace” option.

The pattern ExUnit uses is: "test #{describe_text} #{test_text}". So the end result could be something like:

“test some_function/1 it authenticates properly”

This is strange to read. But to make it more plausible we would have to add a strange clause to desribce like describe "that some_function/1" do ... end. So on the report it would be:

“test that some_function/1 succeeds with an active user”

We could use a different approach and use the action directly:

“test some_function/1 can authenticate an active user”

What are your thoughts on good unit testing naming? Sorry for English mistakes. Altough I am picking on the grammar here, English is not my mother’s tongue.


#2
describe "MyModule.my_function/1" do

  test "authenticates successfully with valid parameters" do
  end

  test "fails authentication with invalid parameters" do
  end

end

#3

Test user can authenticate normally
Test authentication via google account
Test registration via google account
Test user cannot authenticate when wrong username / password
Test user cannot register with invalid mail format
Test user can add item to cart
Test user cannot add out of stock item to cart
Test calculation of order discount
Test completed order not to be editable
Test driver can pickup customer
Test driver can complete customer’s order
Test blocked user cannot comment on user’s post
Test unregistered visitor can see products

And so on… I kinda think that test is equal to specify in rspec.
it and specify in rspec is just the same, but it is usually followed by verbs.

it should
it must
it allows
it forbids