Unit Testing and the Arrange, Act and Assert (AAA) Pattern
The AAA (Arrange-Act-Assert) pattern has become almost a standard across the industry. It suggests that you should divide your test method into three sections: arrange, act and assert. Each one of them only responsible for the part in which they are named after.
So the arrange section you only have code required to setup that specific test. Here objects would be created, mocks setup (if you are using one) and potentially expectations would be set. Then there is the Act, which should be the invocation of the method being tested. And on Assert you would simply check whether the expectations were met. More info can be found HERE.
Following this pattern does make the code quite well structured and easy to understand. In general lines, it would look like this:
// arrange
var repository = Substitute.For<IClientRepository>();
var client = new Client(repository);// act
client.Save();// assert
mock.Received.SomeMethod();
// Challenge
Please notice the comments that precedes each section. Have you ever thought whether you really need them on every single test?
Well, the answer may depend on the developer’s OCD levels. I guess if you think that clean code should be self-explanatory, as you were reading an English text (or whatever other language for that matter), then it would look quite silly to preempt every section of your text with what is coming next. If that does not sound like a good idea, why should we do that on our code?
// Reasons why this isn’t a good idea
Your test code should respect most, if not all, rules of production code. It should avoid meaningless magic numbers, should avoid violating principles like DRY, YAGNI, SRP and KISS.
// Possible reasons why people do this
While learning a new technique, it can be useful to tricks to reenforce it. Like when learning a foreign language, a teacher would provide templates or pre-populated structures that you just need to fill-in the gaps. The same is here, when you starting with your first tests it does make sense to make those comments so you are doing it right.
Once the student has mastered the technique, and that skill becomes second nature, the template should no longer be necessary.
// Closing points
Test code, in the same way as production code, is supposed to be clean and self-explanatory. Preempting what you are going to do just adds unnecessary clutter. You can still have a clear distinction of the three steps by using spaces and indentation. Which are ultimately the key features the compiler provides you to structure your code.
It does look silly having a comment preceding each paragraph in this text, it tires the reader, as it has to constantly go through the obvious (or skip it). So why would you do that with your code?
