Changes for page Testing Principles
Last modified by chrisby on 2024/04/01 12:52
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -5,7 +5,7 @@ 5 5 ** **Meaningful Tests:** Don't add tests that don't add value or test something that has already been tested. 6 6 7 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. 8 -* **Falsifiability** = The ability to fail. False-negativetests are easy tocatch, but false-positivetests aren't, which is what makes themsotricky. Use TDD, and get into the habit of mutating the critical section of production code to trigger the test failure, see [[TDD article>>doc:Tutorials and Guides.Test-Driven Development Workflow with Git.WebHome]]. A test should fail before production code is written. Tests without assertions always pass, which is why the assertion should be the first thing written in a test to prevent forgetting it.8 +* **Falsifiability** = The ability to fail. Wrongfully failing tests are easy to detect, because a good developer will pay attention to all failing tests and fix the problem before moving on. Wrongfully passing tests 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. Use TDD, and get into the habit of mutating the critical section of production code to trigger the test failure, see [[TDD article>>doc:Tutorials and Guides.Test-Driven Development Workflow with Git.WebHome]]. A test should fail before production code is written. Tests without assertions always pass, which is why the assertion should be the first thing written in a test to prevent forgetting it. 9 9 * **Determinism**: Repeated tests should always produce the same result. The success of tests should never depend on anything other than the production code. Avoid sources of randomness that could cause the test to fail only some of the time. These include random number generators, threads, host-specific infrastructure (operating system, absolute paths, hardware: I/O speed or CPU load), networking over the local network or Internet, time/timestamps, pre-existing values in the database or files on the host system that are not in the source code. 10 10 * **Single Action Execution**: The entire setup and testing process should require a single click or shell command. Otherwise, they will not be used regularly, which reduces the quality assurance of the production code. 11 11 * **Independence**: Tests should be independent and not influenced by other tests; the order in which tests are executed should not matter.