APIs, interfaces, and component design.
3 posts, grouped by toolchain
Each unit test should verify one specific behavior. Avoid exercising multiple behaviors or features within a single test case.
Tip
A useful heuristic: if you cannot describe what a test checks without using “and”, it is testing more than one behavior and should be split.Prefer testing the public interface of a unit over its private implementation details. A test should exercise what a unit promises to its callers, not how it achieves it internally. This style is called black-box testing: the tester knows the external behavior but treats the internal structure as opaque.
Tip
If you find yourself needing to reach into private helpers to test them, that is usually a design smell. Consider extracting those helpers into their own unit with its own public interface, and test them there.Do not write code that detects whether it is running under test and changes its behavior – test-aware code. A unit that branches on a test flag, the presence of a test runner, the presence of an environment variable, or a test-only build runs a different path under test than it does in production, so the test verifies behavior you do not ship. Instead, make code testable through design – typically dependency injection – so that tests substitute collaborators without the unit ever knowing.
Tip
If a test only passes because the code skipped its real work, the test is exercising the test-mode path, not the production behavior. It has little value as a test.Each unit test should verify one specific behavior. Avoid exercising multiple behaviors or features within a single test case.
Tip
A useful heuristic: if you cannot describe what a test checks without using “and”, it is testing more than one behavior and should be split.Prefer testing the public interface of a unit over its private implementation details. A test should exercise what a unit promises to its callers, not how it achieves it internally. This style is called black-box testing: the tester knows the external behavior but treats the internal structure as opaque.
Tip
If you find yourself needing to reach into private helpers to test them, that is usually a design smell. Consider extracting those helpers into their own unit with its own public interface, and test them there.Do not write code that detects whether it is running under test and changes its behavior – test-aware code. A unit that branches on a test flag, the presence of a test runner, the presence of an environment variable, or a test-only build runs a different path under test than it does in production, so the test verifies behavior you do not ship. Instead, make code testable through design – typically dependency injection – so that tests substitute collaborators without the unit ever knowing.
Tip
If a test only passes because the code skipped its real work, the test is exercising the test-mode path, not the production behavior. It has little value as a test.Each unit test should verify one specific behavior. Avoid exercising multiple behaviors or features within a single test case.
Tip
A useful heuristic: if you cannot describe what a test checks without using “and”, it is testing more than one behavior and should be split.Prefer testing the public interface of a unit over its private implementation details. A test should exercise what a unit promises to its callers, not how it achieves it internally. This style is called black-box testing: the tester knows the external behavior but treats the internal structure as opaque.
Tip
If you find yourself needing to reach into private helpers to test them, that is usually a design smell. Consider extracting those helpers into their own unit with its own public interface, and test them there.Do not write code that detects whether it is running under test and changes its behavior – test-aware code. A unit that branches on a test flag, the presence of a test runner, the presence of an environment variable, or a test-only build runs a different path under test than it does in production, so the test verifies behavior you do not ship. Instead, make code testable through design – typically dependency injection – so that tests substitute collaborators without the unit ever knowing.
Tip
If a test only passes because the code skipped its real work, the test is exercising the test-mode path, not the production behavior. It has little value as a test.Each unit test should verify one specific behavior. Avoid exercising multiple behaviors or features within a single test case.
Tip
A useful heuristic: if you cannot describe what a test checks without using “and”, it is testing more than one behavior and should be split.Prefer testing the public interface of a unit over its private implementation details. A test should exercise what a unit promises to its callers, not how it achieves it internally. This style is called black-box testing: the tester knows the external behavior but treats the internal structure as opaque.
Tip
If you find yourself needing to reach into private helpers to test them, that is usually a design smell. Consider extracting those helpers into their own unit with its own public interface, and test them there.Do not write code that detects whether it is running under test and changes its behavior – test-aware code. A unit that branches on a test flag, the presence of a test runner, the presence of an environment variable, or a test-only build runs a different path under test than it does in production, so the test verifies behavior you do not ship. Instead, make code testable through design – typically dependency injection – so that tests substitute collaborators without the unit ever knowing.
Tip
If a test only passes because the code skipped its real work, the test is exercising the test-mode path, not the production behavior. It has little value as a test.