Pyramid test principle: 8 tips for writing unit tests

You must be familiar with the principle of pyramid test , In recent years, test driven openness has become popular in various companies , The initiative of writing test code first is mentioned repeatedly .

In view of this , Many large and medium-sized software companies have gradually increased their requirements for unit testing . that , What tips can I learn from writing unit tests ？

Test code file path and development code file path “ identical ”

there “ identical ” Not exactly the same , Test code and development code are in the same directory , It refers to the test code file path and the development code file path “ Basically the same ”.

Here's the picture 1、2 Shown , Both the development code path and the test code path include /java/ru/yandex/clickhouse/.

chart 1 Development code path

chart 2 Test code path

The test code file name is clear

A clear test code file name can help other personnel reading the test code to have a good preliminary understanding of the test content of the file .

For example, the picture above 2 Shown ： Test code file ClickHouseConnectionTest.java, The naming can help readers know that the test code file is for ClickHouseConnection.java Test of .

Clearly name the unit test name

Don't worry about long names , A long and complete name will let you know immediately which test failed , And what the test really wants to do .

Long named tests can also record your tests . Here's the picture 3 Shown ： from testMaxMemoryUsage() The name shows that the test code tests for the maximum memory usage . Obvious , The name is far better than test1()、test()2……

chart 3 Example of unit test name

Test one at a time

Same as integration test 、 The system testing principles are consistent , Test cases should remain “ Exclusivity ” principle , That is, only one function is tested for each test .

Here's the picture 4 Shown ： All aimed at clickhouse To configure , Then launch the function of query , But the top of the figure is mainly for the test set for the maximum execution event , Below is a test of the maximum memory usage setting .

chart 4 unit testing “ Exclusivity ” Examples

Tests remain independent

Test independence refers to different test cases / There should be no dependencies between code blocks （ Such as ：test2() Code dependencies for test1() Parameter settings in ）, Each test case / Code blocks should be able to run independently .

In view of this , We can put some common configurations （ Such as database initialization ） Extract to test suite / Code file initialization .

Clearly throw the test failed exception

The test case / Code does not guarantee success every time it runs （ For example, the test code fails due to the refactoring of the development code or the function change ）, Therefore, when writing test code, you need to catch exceptions in case of failure , And clearly return to .

for example ： If you use Integer aa=1;Integer bb=2;Assert.assertTrue(aa==bb); Code judges variables aa and bb Whether it is equal or not , If they are not equal, they will only be judged as failure without detailed error information .

If it's changed to Assert.assertEquals(aa, bb); Will return a similar Expected 1, but the actual result was 2 Information about , Such error messages are more valuable .

Don't be obsessed with test coverage

When it comes to unit testing , You will think of test coverage . Test coverage mainly refers to code path coverage and branch coverage .

When writing unit tests, you will inevitably fall into a blind pursuit 100% Test coverage pitfalls .100% Test coverage is a difficult vision to achieve ,100% The coverage of does not mean that you have covered all the edge cases , It just means that all code paths are executed .

During the actual test , We should focus on whether the test function is covered, rather than whether the unit code path is completely covered . for example ： For files with the same code （ Copy and paste the same code block ）, Pursuit 100% The test coverage of will lead to test redundancy .

therefore , We should write unit test cases from the perspective of ensuring normal functions , Instead of writing unit test cases for each unit function .

that , How to write unit test cases from a functional perspective ？ The simplest point is to look at the function module being called .

If a module is called by an upper function function , Then this module requires us to write unit test cases to guard .

It's better to have notes

Comments can help other code readers understand the code faster , Unit tests are also code , So developing the habit of commenting can improve your code writing skills .

Classify unit test cases appropriately , Improve operational efficiency

Unit test cases and integration test cases 、 System test cases are the same , When the number of test cases becomes large , It is cumbersome to modify part of the code and run all the unit test cases every time .

At this time, if your unit test cases have a clear classification , Then we can improve the operation efficiency .

Here's the picture 5 Shown ： The unit test label is ”unit”, At run time, it can be based on “unit” Tab select the unit test case .

chart 5 Sample unit test label

Above unit test tips , Hope to help you unit test beginners .