Changes for page Tips and Tricks

Summary

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

Details

Page properties

Content

...	...	@@ -7,7 +7,7 @@
7	7	*1. **when** (something happens → execute production code)
8	8	*1. **then** (a certain outcome is expected → check the result via assertions)
9	9	** Alternative common names for the three steps: **arrange, act, assert**
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.
	10	+* Use additional **simple high-level checks**. Use additional simple high-level checks. For example, when working with a collection, checking the number of items before examining an item from the collection in detail is a good indicator of unexpected or missing items.
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	12	* **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.
13	13	* **Avoid threads**
...	...	@@ -60,4 +60,4 @@
60	60	* **Range-Based Assertions**: Inaccurate results should never be asserted against an exact value, but only within an expected range of approximation. This includes all assertions of floating-point numbers.
61	61	* **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.
62	62	* **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.
63		-* **Separate code to be 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.
	63	+* **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.