You've probably heard about the Arrange-Act-Assert (also known as Given-When-Then) test pattern by now, but in case you haven't, let me briefly introduce you to it. The idea is to split your test into three parts:
- Arrange: Prepare the context. Also called the "Given" part, as in "Given I have 100 bucks on my account.."
- Act: Do something. Also called "When", as in "..when I withdraw 40 dollars.."
- Assert: This is the part where you check the result. Also called "Then": "..then I have $60 left".
In other words, first you prepare some context, then do something, then check the results. Some folks also include a fourth stage, at which you return the system to its previous stage (like, delete all created files, apologize for all unsolicited email sent during the test, etc.), but that's not really relevant. What's relevant as far as this post is concerned is the following shocking truth I'm going to throw upon your unsuspecting minds.
The AAA syntax is much more than just adding comments and empty lines to your test method. It can be an important step towards making your tests much, much more manageable and robust.
The starting point for effectively using this idea is to put these three stages into three different methods.
Now, you can still write a simple test method and just divide it into three stages for clarity, leaving them in the same method but dividing them with comments and empty lines. But if you want to use it as a powerful tool, you have to treat all three differently.
Moving the Setup to a Different Place
The first thing you can do without much effort is to put the first two As in a different method. Most test frameworks support this. For example, in NUnit and mbUnit, you can decorate a method with the FixtureSetup attribute, and it will be executed once before all test methods in the class. In other frameworks, like xUnit, a new instance is created for each test method, so you'll have to put the setup code into the constructor or, if it's expensive to run, into a static method.
Why Should I Bother?
You shouldn't. Just do it in a relaxed way.
Seriously, there are numerous reasons:
- Separation of concerns. If you apply it to your production code, why not apply it to your tests? At least, you should have one method prepare stuff for testing, another one for testing this stuff. Perhaps you should have different classes for these two, but let's discuss it in another post.
- It helps you organize your test classes by context, rather than just throw in more and more test methods until your test class is too big to fit on your hard drive. More on that in another post.
- It lets you put your asserts in different methods, leaving only one (logical) assertion in a single test method, which is good for various reasons, which deserves a separate post. If you do it properly, you end up with tests having a single line (or two) each.
Sometimes It's Not the Best Solution
- When you write your test for a demo purpose (I will, sometimes, in this blog), it's easier to understand what's going on when you put everything in the same method, provided it's not too long. Still, it's a good idea to mark the three stages in comments.
- When your tests are really small, and you have no common setup code. Like calculator tests used when teaching TDD, but seldom happens in real life.
- When you are forced to use a fixture-per-class pattern. Personally, I think it's a really bad idea, but chances are you simply don't have a choice.
More Stuff Coming
The Arrange-Act-Assert pattern is a topic I could write about for hours. This is just the first post in a series. Until next time!
