Changes for page Testing Principles

Summary

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

Details

Page properties

Content

...	...	@@ -11,7 +11,7 @@
11	11	* **Independence**: Tests should be independent and not influenced by other tests; the order in which tests are executed should not matter. Promote test independence by **avoiding mutable states**. Use constants for shared data between tests where feasible. For mutable shared data that may be modified by tests, **setup methods** typically initialize instance variables before each test to ensure correct values. The class or application under test can be restored to its original state by calling **cleanup methods** after each test.
12	12	* **Self-Containment**: For reliability, test results should depend only on the source code to support reproducibility, and not on external factors such as potentially unstable network connections.
13	13	* **Clean Test Code**: Maintain the same high standards for test code as for production code. The only exception is execution speed - tests need to be fast, but not highly optimized, as they typically deal with only small amounts of test data.
14		-* **Easy Bug Tracing**: Failed tests should clearly indicate the location and reason for the failure. Measures to achieve this could include using only **one assertion per test**, using **error logs** immediately when a problem occurs, and using **unique exceptions and error messages** where appropriate.
	14	+* **Easy Bug Tracing**: Failed tests should clearly indicate the location and reason for the failure. Measures to achieve this could include using only **one assertion per test**, using **error logs** where a problem occurs the first time, and using **unique exceptions and error messages** where appropriate.
15	15	** Having only one assertion per test is often a good guideline, but not a strict one, since it's sometimes practical to include multiple assertions within a single test if they are closely related and together validate a specific behavior.
16	16	* **Test behavior, not implementation**: Focus on testing the expected results, not the specific ways in which they are achieved. Tests should not know implementation details. Developers should be free to change production code without breaking tests, as long as the expected results remain consistent. This reduces the tight coupling between test and production code, resulting in more resilient tests that don't need to be constantly updated with every production code change. Therefore, avoid weakening encapsulation by making private things public or using reflection. However, weakening encapsulation is a lesser evil than not testing at all.
17	17	* **Test requirement fulfillment over specific solutions:** Don't limit tests to a specific solution when multiple valid solutions exist. Test for compliance with the solution requirements, not the specific output, as this provides flexibility by accepting any valid solution. For example, in pathfinding problems, minimum travel costs validate a solution, not the particular path chosen. If the solution requirement is complex, it may even be worthwhile to implement a verification algorithm in the test code, since a little complexity is the lesser of two evils compared to not testing at all.