How do you check an idea before trusting it? A unit test is an automated check of a small, isolated piece of software. It turns a programmer’s assumption into something executable: does this behavior actually produce the expected result? section 5.2.1
Unit tests are especially valuable when code feels like a fragile Jenga tower. Tests can raise confidence before changes enter a shared codebase, even when the system is old, tangled, or difficult to understand. They do not replace critical inspection: breakpoints, stepping through unclear code, and integration tests may still be needed. section 4.3 section 5.2.1
A useful unit test habit is to:
- Choose one behavior to check rather than trying to prove that an entire system works. section 4.3
- State the expected result clearly, run the test, and investigate failures instead of assuming the original idea was correct. section 5.2.1
- Use the result to make risky changes feel possible, while remembering that a test suite is useful only when the team is willing to rely on it. section 4.3
A tiny assertion
A readable test names an operation, supplies an argument, and asserts the expected result: MyTestMethod_WithSomeArg_ShouldReturn45 calls MyTestMethod(arg1), then checks that the result equals 45. The same pattern can make unfamiliar legacy code less frightening. section 4.3
Public Sub MyTestMethod_WithSomeArg_ShouldReturn45 Dim isType As Boolean isType = MyTestMethod(arg1) Assert.That isType, Iz.EqualTo(45) End Sub
Inspect the compact test listing to see how a named behavior, invocation, and expected value fit together. section 4.3
