Changes for page Testing Principles

Summary

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

Details

Page properties

Content

...	...	@@ -15,7 +15,7 @@
15	15	* **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.
16	16	* **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**, and using **unique exceptions and error messages** where appropriate.
17	17	* **Test behavior, not implementation.** Run tests against interfaces from production code to test the implementation behind them. The developer should be free to modify the code as long as it produces the correct results. This also reduces the coupling between test and production code, resulting in less work to adapt tests when the implementation changes. Avoid reflection and weakening encapsulation by making private things public. However, weakening encapsulation is a lesser evil than not testing at all.
18		-* **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 code change. Therefore, avoid reflection and weakening encapsulation by making private things public. However, weakening encapsulation is a lesser evil than not testing at all.
	18	+* **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.
19	19	* **Requirement fulfillment over specific solutions:** Don't limit tests to a specific solution when multiple valid solutions exist. Test for compliance with solution requirements, not the specific output. This provides flexibility by accepting any valid solution. For example, in pathfinding problems, minimum travel costs validate a solution, not the particular path chosen.
20	20	* **'Program testing can be used to show the presence of bugs, but never show their absence.' **(Edsger W. Dijkstra).
21	21	** Follow good testing practices to avoid a large number of bugs, but be aware that bugs may still occur and be prepared for them.