Changes for page Tips and Tricks

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,6 +1,6 @@
1	1	Here are a few general guideline that help to write better test code as well as influencing the design of the production code.
2	2
3		-* **Regular Execution**: Run tests regularly, ideally before every commit, for optimal quality assurance. In particular, run all relevant tests before pushing code or creating a pull/merge request. 'Continuous integration' practices are helpful for enforcing testing of code uploaded by other developers.
	3	+* **Frequent Execution**: Run tests frequently, ideally before every commit, for optimal quality assurance. In particular, run all relevant tests before pushing code or creating a pull/merge request. 'Continuous integration' practices are helpful for enforcing testing of code uploaded by other developers.
4	4	* Use **functional programming** for data processing tasks because it is less prone to errors and side effects.
5	5	* It's common to create **test users and test data** to facilitate the testing process.
6	6	* Don't reinvent the wheel and **use existing test libraries**. There are proven solutions that minimize the effort of creating tests.
...	...	@@ -63,3 +63,4 @@
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	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.
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	+* **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%.