Skip to Content

Changes for page Tips and Tricks

Last modified by chrisby on 2024/04/01 13:11
From version 1.37
edited by chrisby
on 2024/04/01 13:02
Change comment: There is no comment for this version
To version 1.38
edited by chrisby
on 2024/04/01 13:03
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -59,8 +59,8 @@
59 59  
60 60  * **Test Case Logging**: If certain production code needs to be called several times with slightly different arguments, it may be useful to iterate over a list of these arguments, calling the production code and then asserting the result on each iteration. It is then often good practice to print out each element of the list before each assertion. If an element causes a test to fail, the terminal output will immediately show which element caused the error.
61 61  * **Bug Coverage Responsibility**: If you find a bug or a case that has not yet been tested, it is your duty to create a test that covers it, so that the software is stable against that problem from that moment on.
62 -* **Range-Based Assertions**: Potentially inaccurate results should never be asserted against an exact value, but only within an expected range of approximation. This includes all assertions on floating-point numbers, which may vary slightly on different operating systems, compilers or CPUs.
62 +* **Range-Based Assertions**: Potentially inaccurate results should never be asserted against an exact value, but only within an expected range of approximation. This includes all assertions on floating-point numbers, which may vary slightly between different operating systems, compilers, or CPU architectures.
63 63  * **Avoid Cascading Validation**: It would be very cumbersome to perform input validations, such as the famous null checks, and corresponding tests for each unit. A common solution is to define a module consisting of several units. The unit at the top, which receives the input for the first time, validates it once. All subsequent units can safely assume that the input is not null when processing it, and no longer need to explicitly check or write tests for such cases.
64 -* **Stick to Performance Requirements**: Once a performance test is passed, there is no need to optimize the performance of the code. Any effort in that direction is a waste of resources.
64 +* **Stick to Performance Requirements**: Once a performance test is passed, there is no need to further optimize the performance of the code. Any effort in that direction is a waste of resources.
65 65  * **Separate code to be unit tested from third-party code**. All third-party libraries should be hidden behind an interface + wrapper anyway. The unit to be tested should use the interface, which is easy to mock, instead of directly using the third-party library, which is hard to mock.
66 66  * **Proportion of test code in the code base**: A comprehensive test suite is critical to keeping the functionality of a software stable when changes are made to the code base. Therefore, it is not uncommon for test code to make up a large portion of the total code base, such as 30-50%.