Principle 1: Write the Tests First
AKA: Test-Driven Development, Test First Development
Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes.
Principle 2: Design for Testability
Testability is visibility and control. Visibility is our ability to observe the states, outputs, resource usage and other side effects of the software under test. Control is our ability to apply inputs to the software under test or place it in specified states.
Bach describes testability as composed of the following.
• Control. The better we can control it, the more the testing can be automated andoptimized.
• Visibility. What we see is what we test.
• Operability. The better it works, the more efficiently it can be tested.
• Simplicity. The less there is to test, the more quickly we can test it.
• Understandability. The more information we have, the smarter we test.
• Suitability. The more we know about the intended use of the software, the better wecan organize our testing to find important bugs.
• Stability. The fewer the changes, the fewer the disruptions to testing
Principle 3: Use the Front Door First
AKA: Front Door First
Objects have several kinds of interfaces. There is the "public" interface that clients are expected to use and there may also be a "private" interface that only close friends should use. Many objects also have an "outgoing interface" consisting of the used part of the interfaces of any objects on which they depend. The types of interfaces we use has an influence on the robustness of our tests.
Principle 4: Communicate Intent
AKA: Higher Level Language, Single Glance Readable
A test should visibly tie the expected outcome to theconditions that should cause it. A quick read of a test should be enough to understand what it tests.
The test should fit in a single pane of the window without scrolling.
Principle 5: Don't Modify the SUT (System under test)
Principle 6: Keep Tests Independent
AKA: Independent Test
Each test is self-contained and makes no assumptions about what other tests have run before it or will run after it.
Principle 7: Isolate the SUT
Principle 8: Minimize Test Overlap
Principle 9: Minimize Untestable Code
Principle 10: Keep Test Logic out of Production Code
AKA: No Test Logic in Production Code
Principle 11: Verify One Condition per Test
AKA: Single Condition Test
Tests should verify a single test condition (a single scenario).
Principle 12: Test Concerns Separately
Principle 13: Ensure Commensurate Effort and Responsibility
