Changes for page Tips and Tricks

Summary

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

Details

Page properties

Content

...	...	@@ -1,4 +1,4 @@
1		-* **Regularity:** 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.
	1	+* **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.
2	2	* Use **functional programming** for data processing tasks because it is less prone to errors and side effects.
3	3	* It's common to create **test users and test data** to facilitate the testing process.
4	4	* Don't reinvent the wheel and **use existing test libraries**. There are proven solutions that minimize the effort of creating tests.
...	...	@@ -9,7 +9,6 @@
9	9	** Alternative common names for the three steps: **arrange, act, assert**
10	10	* Use additional **simple high-level checks**. Use additional simple high-level checks. For example, when working with a collection, checking the number of elements is a good indicator of unexpected or missing elements.
11	11	* **More is better.** When in doubt, it is better to write one test too many than one test too few. Possible duplication is a lesser evil than not testing at all.
12		-* Also **test non-functional aspects** such as security, single request computation performance, and perform load/stress testing to validate software throughput.
13	13	* **Keep test resources close to the tests** to make their use easy to understand. Test resources should be placed in the same location as the test if the resource is only needed by that test.
14	14	* **Avoid threads**, as they are usually buggy and very difficult to test and debug properly. If threads are necessary, keep the amount of asynchronous code to a minimum. Also, separate synchronous and asynchronous logic to test them separately. Prefer thread termination conditions over fixed wait times, as this usually increases test performance dramatically.
15	15	* **Avoid files**
...	...	@@ -52,8 +52,8 @@
52	52	assertTrue(y);
53	53	{{/code}}
54	54
55		-* 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 before each assertion. If an element causes a test to fail, the terminal output will immediately show which element caused the error.
56		-* 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.
57		-* Inaccurate results should never be asserted against an exact value, but only within an expected range of approximation. This includes all floating-point numbers, which are always imprecise.
58		-* Don't exclusively test third-party code, such as other services or libraries. It's not your job, and it's probably a duplication of effort. Only test if it works correctly with your own code.
59		-* 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 classes. The class at the top, which receives the input for the first time, validates it once. All subsequent classes can safely assume that the input is not null when processing it, and no longer need to explicitly check it.
	54	+* **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 before each assertion. If an element causes a test to fail, the terminal output will immediately show which element caused the error.
	55	+* **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.
	56	+* **Range-Based Assertions**: Inaccurate results should never be asserted against an exact value, but only within an expected range of approximation. This includes all floating-point numbers, which are always imprecise.
	57	+* **Focus on Own Code**: Don't exclusively test third-party code, such as other services or libraries. It's not your job, and it's probably a duplication of effort. Only test if it works correctly with your own code.
	58	+* **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 classes. The class at the top, which receives the input for the first time, validates it once. All subsequent classes 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.