{"id":3688,"date":"2014-04-01T10:47:47","date_gmt":"2014-04-01T13:47:47","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=3688"},"modified":"2014-04-01T13:31:03","modified_gmt":"2014-04-01T16:31:03","slug":"improve-your-test-readability-using-the-xunit-structure","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2014\/04\/improve-your-test-readability-using-the-xunit-structure\/","title":{"rendered":"Improve your test readability using the xUnit structure"},"content":{"rendered":"

TL;DR:<\/strong> test quality is not just about verifying correctly whether your code works, it’s also about making your test easy to read and understand. You can do that by structuring your test using the four-phases xUnit standard.<\/p>\n

\n <\/p>\n

The 4 phases of a test: setup, exercise, verify and teardown<\/p>\n<\/div>\n

People don’t write tests to be read, they write them to be executed<\/h3>\n

One of the main reasons to write tests is to have an automated way to check if your code is doing what you expect it to do. That means, trying to verify its correctness. Your test suite acts as a safety net that guarantees your software will continue to work as expected while you refactor, build new features or fix bugs. That’s amazing! But, throughout the years, software developers discovered that tests can be even more than a safety net.<\/p>\n

Write tests as examples of how to use your code<\/h3>\n

A test is an example of how to use your code, not just a way to verify its correctness. Seeing tests as examples of how to use your code changes a little bit the priorities you have when writing them. If the test should serve as an example, then it should be easy to read and understand. Therefore, you should also focus on test readability, not just test “executability” (I know, weird word). One way to improve readability of a piece of text (or code) is to write it in a way the readers are used to, a structure that they expect, some standard way… Let’s think about that.<\/p>\n

Back at your school days, you learned that when writing an essay, you’re supposed to structure it in: introduction, body and conclusion. Why? Because that structure helps you to better express your ideas. That means, it helps the reader to understand your message. Is there any equivalent of that for automated tests writing? In fact, there is. It’s called the xUnit structure.<\/p>\n

Structure your tests using the xUnit standard<\/h3>\n

First, let’s see a test that can have its readability improved:<\/p>\n

\ndescribe Stack do\n  describe \"#push\" do\n    it \"puts an element at the top of the stack\" do\n      stack = Stack.new\n      stack.push(1)\n      stack.push(2)\n      expect(stack.top).to eq(2)\n    end\n  end\nend\n<\/pre>\n
One can understand the test above, but still, it’s not easy to quickly scan the test and see that it has logical parts. Those parts would be the the xUnit phases<\/a>.<\/p>\n
The standard xUnit test structure is composed of 4 phases: setup, exercise, verify and teardown.<\/p>\n