Your tests can also be your documentation

Tests help as make sure that our code works, provide us a safety net when we need to refactor and, when having proper test names, can be a good documentation describing what the code does.

The last one can be especially helpful for both newcomers that need to understand the system and old timers that haven’t visited the code for a while!

A couple of tricks for achieving good names are:

1. Avoid describing how the code does something and try to describe what it does For example: calling add(item) results in calling recalculate is way too specific without providing anything meaningful, or anything that we wouldn’t get from reading the code. On the other hand: a recalculation of the order's value takes place every time a new item gets added shares an important information about the Order‘s behavior when adding an item.
2. Avoid being too abstract For example: a customer can buy alcohol when she is of legal age can help the reader understand how the code behaves but in a documentation you need specific values. So: a customer can buy alcohol when she is older than 21 years of age is much better because it also provides the exact threshold that our code considers for allowing someone to buy alcohol