Unit testing is essential for delivering high quality software. We know that testing gives you confidence when implementing new releases or refactoring. These tests positively impact the design class. Name tests act as live documentation.
The benefit of the unit tests is undeniable. We obtain these benefits when we write tests that are readable and easy to maintain, and this is not always a rule.
Can you have thousands of test units and at the same time be afraid of each application roll-out? Unfortunately yes.
Could a minor change to your code brake hundreds of tests.? Unfortunately yes.
It is possible although we have hundreds of unit tests, base on those test namse we don’t know what how feature? Unfortunately yes.
Unit Tests can accelarates or slow down our development process. Depents how we will implement and maintain them.
I would like to show you some practical tips which can help you write cleaner tests.
Test Names
Test names are crutial they are describe our unit of testing behavior and expectation.
- For the people that see first time functionality they should be documentation.
- For code reviewe missing edge can be detected quicker.
- For QA gives information what was tested and what shouldn’t be covered by manual/Automation QA tests
Like you can see descriptive test names are important.
Diffrent teams has diffrent naming convetion.
In my opinion each convetion has to have tree parts.
- Tested method name
- Conditions
- Expected Result
My favorite one is Gherkin syntax taken from BDD
Pattern: Given_TestMethodName_When_Conditions_Then_ExpectedResult
Take a look at the test names. They are mostly understandable for non-technical persons. They contains business languange. Given, When, Then makes them even easier to read as natural language sentences.
For me key to good name unit test name is simplicity. We should be concentrating during naming tests on what we want to achieved by implementation code from business process perspective. We should use domain language where is possible.
