Changes for page Testing Principles

Summary

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

Details

Page properties

Content

...	...	@@ -16,5 +16,5 @@
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 test code complexity is the lesser of two evils compared to not testing at all.
18	18	* **'Program testing can be used to show the presence of bugs, but never show their absence.' **(Edsger W. Dijkstra). Follow good testing practices to avoid a large number of bugs, but be aware that bugs may still occur and be prepared for them.
19		-* **Fast**: Tests should be small and fast, which means, for example, that there is no need to test million data points, but maybe 5, each covering just one specific use case or border case. The exceptions are load/stress tests, which are specifically designed to send huge amounts of data to an application.
	19	+* **Fast**: Tests should be small and fast. For example, that there is no need to test million data points, but maybe 5, each covering just one specific use case or border case. The exceptions are load/stress tests, which are specifically designed to send huge amounts of data to an application.
20	20	* **Specific Assertions**: Broad or generic assertions may fail to distinguish between closely related use cases. For example, asserting a thrown exception by catching a generic superclass fails to distinguish between potentially different error cases represented by different exception subclasses. The takeaway from this example is to always assert the exact type of exception thrown or the specific error message returned.