Changes for page Tips and Tricks

Summary

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

Details

Page properties

Content

...	...	@@ -1,3 +1,5 @@
	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	+
1	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.
...	...	@@ -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 items before examining an item from the collection in detail is a good indicator of unexpected or missing items.
	12	+* 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**
...	...	@@ -17,9 +17,9 @@
17	17	** Prefer thread termination conditions over fixed wait times, as this usually increases test performance dramatically.
18	18	* **Avoid files**
19	19	** I/O is slow increasing the test time unnecessarily.
20		-** Temporary files may persist because you forgot to delete them or put them in folders where they will never be found. At the very least, be sure to delete files at the very beginning of the test to ensure their absence. Deleting files at the end of a test is prone to erros because if the test fails/aborts, those files may persist and affect subsequent tests.
	22	+** Temporary files may persist because you forgot to delete them or put them in folders where they will never be found. At the very least, be sure to delete files at the very beginning of the test to ensure their absence. Deleting files at the end of a test is prone to errors because if the test fails/aborts, those files may persist and affect subsequent tests.
21	21	** Prefer data streams over files for testing.
22		-* **Don't leave tests unfinished**, don't just comment out @Test (annotation in Java to mark a function as a test), and don't leave empty test bodies as these things are confusing and waste the reader's time. If you come across this kind of code, try to learn its purpose, ask people who worked on it, and rebuild it. If that is not possible or worth the time, then delete it as the dead code that it is. To indicate that tests need to be implemented, an issue/work unit could be created and referenced, or a TODO comment with an explanatory description could be added.
	24	+* **Don't leave tests unfinished**, don't just comment out @Test (annotation in Java to mark a function as a test), and don't leave empty test bodies as these things are confusing and waste the reader's time. If you come across this kind of code, try to learn its purpose, ask people who worked on it, and try to finish the implementation. If that is not possible or worth the time, then delete it as the dead code that it is. To indicate that tests need to be implemented, an issue/work unit could be created and referenced, or a TODO comment with an explanatory description could be added.
23	23	* **A test should fail if an expected exception is not thrown.** Test libraries usually have methods to handle such cases. If the exception object must be examined, use a try-catch block that includes a fails() method at the end of the try block. Without the fails() method to make the test fail, the test would wrongfully pass if no exception were thrown:
24	24
25	25	{{code}}