Changes for page Tips and Tricks

Summary

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

Details

Page properties

Content

...	...	@@ -24,7 +24,7 @@
24	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.
25	25	* **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:
26	26
27		-{{code}}
	27	+{{code language="none"}}
28	28	try {
29	29	//code that should throw exception
30	30	fails(); //executed when no exception was thrown
...	...	@@ -36,7 +36,7 @@
36	36	* **Different branches** of production code should be checked in different tests.
37	37	* **Avoid if-statements in the test code**, but at least be careful with assertions in if/if-else blocks, as the test may pass without executing them. To prevent this, here are a few suggestions:
38	38
39		-{{code}}
	39	+{{code language="none"}}
40	40	// bad - still passes when x == false and y == false
41	41	if (x){
42	42	//some logic
...	...	@@ -57,7 +57,7 @@
57	57	assertTrue(y);
58	58	{{/code}}
59	59
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 before each assertion. If an element causes a test to fail, the terminal output will immediately show which element caused the error.
	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	62	* **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.
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.