Skip to content
academia.sh

Course Intermediate

Unit Testing and Test-Driven Development

By the end of this course

Start course

01

Unit Testing in Practice

The three parts of a unit test, the signal strength of an assertion, test names that describe intent, breaking order dependence, injecting dependencies from outside, the kinds of test double, what statement and branch coverage mean, and the cost of tests bound to an implementation.

  1. 01 The Anatomy of a Unit Test Converting a defect report's reproduction steps into a runnable test, the arrange-act-assert parts of a test body, and the expected value coming from a source independent of the implementation.
  2. 02 Assertions The distinction between equality and deep equality, the signal strength of an assertion measured by the number of corruptions it catches, partial matching cutting an unnecessary bond, and narrowing an error expectation with a matcher.
  3. 03 Test Naming Building a test name from its unit, condition, and expected-result parts, how bundling three rules into one test makes the name misleading, and how the names of passing tests form a readable list of rules.
  4. 04 Fast and Independent Tests Demonstrating the order dependence produced by module-level shared state with a fixed-seed permutation, breaking it with a fresh fixture, and measuring the share an out-of-process fixture adds to run time.
  5. 05 Testable Design Comparing a version that creates its own dependency with a version that receives it from outside, measuring fixture cost in lines, and handing off time and randomness from outside.
  6. 06 Test Doubles Hand-writing the dummy, stub, fake, spy, and mock types, separating the verification question each type answers, and measuring which type speaks up at the same change.
  7. 07 Coverage Measurement Hand-counting statement, branch, and path coverage on the same function, showing with a run the bug a codebase with one hundred percent statement coverage missed, and the limit of using a coverage percentage as a target.
  8. 08 Flaky Tests Implementation-bound tests breaking under a refactor with no behavior change, behavior-bound tests staying green under the same refactor, and flakiness measured with the flake rate.

02

Test-Driven Development

The steps of the red-green-refactor cycle, step size's effect on feedback time, defining a contract with examples, automating the acceptance criterion, and bringing legacy code under test by opening a seam.

  1. 01 Red-Green-Refactor Running each step of the three-step cycle in which the test is written before the code, generalizing a green passed with a fixed value through triangulation, and the guarantee condition of the refactor step.
  2. 02 Progressing in Small Steps Measuring the paths that reach the same rule set with two different step sizes, the relationship between the number of feedback points and the search space for a bug, and the cost of returning to the last green point.
  3. 03 Behavior-Driven Development Defining rules with example tables written in the domain's language, writing a format and a parser for that table, and sustaining the cycle with data-driven tests generated from the table.
  4. 04 Acceptance Test-Driven Development Writing a user request's acceptance criteria in step form, automating them with a driver that binds the steps to the implementation, and a two-layer cycle whose outer loop runs on the acceptance criterion and whose inner loop runs on the unit test.
  5. 05 Bringing Legacy Code Under Test Recording a seamless function's current behavior with characterization tests, making it changeable by opening a parameter seam, and the same tests staying green after the seam.

Start typing to search.

↑↓ Esc navigate · open · close