Changes for page Testing Principles

Summary

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

Details

Page properties

Content

...	...	@@ -4,7 +4,7 @@
4	4	** Leverage **code coverage tools** that determine code coverage during test execution.
5	5	** **Meaningful Tests:** Don't add tests that don't add value or test something that has already been tested.
6	6
7		-* **Strictness**: If at least one test fails, it requires the developer's attention. He is not allowed to proceed with other work until that problem is fixed, and all tests must pass without exception.
	7	+* **Failure Strictness**: If at least one test fails, it requires the developer's attention. He is not allowed to proceed with other work until that problem is fixed, and all tests must pass without exception.
8	8	* **Falsifiability** = The ability to fail.
9	9	** Wrongfully failing tests are easy to detect, because a good developer will pay attention to all failing tests and fix the problems before moving on.
10	10	** Wrongfully passing tests lack the ability to fail properly and are hard to detect because everything seems fine, which is why it is so important to focus on preventing them. They do damage by appearing to validate functionality that they do not. A properly executed Test Driven Development workflow is one of the best ways to avoid these kinds of problems, which are described in [[this article>>doc:Software Architecture.Testing.Test-Driven Development Workflow with Git.WebHome]].
...	...	@@ -18,3 +18,4 @@
18	18	** 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	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	* **Conciseness**: Tests should be small, fast, and specific, which means, for example, that we don't need a million test 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.
	21	+* **Specific assertions**: For example, you should assert exactly what type of exception is thrown or what error (message) is returned. If the assertion isn't specific enough, it might not be able to distinguish between similar problems, such as two exceptions of the same type, so it can't detect potential problems.