Key Points

Introduction to Testing as a Design Tool


  • TDD cycles between the phases red, green, and refactor
  • TDD cycles should be fast, run tests on every write
  • Writing tests first ensures you have tests and that they are working
  • Making code testable forces better style
  • It is much faster to work with code under test

Why We Test: Verification and Validation


  • Testing improves confidence about your code. It doesn’t prove that code is correct.
  • Testing is a vehicle for both software design and software documentation.
  • Creating and executing tests should not be an afterthought. It should be an activity that goes hand-in-hand with code development.
  • Tests are themselves code. Thus, test code should follow the same overarching design principles as functional code (e.g. DRY, modular, reusable, commented, etc).

Parameterized Testing


  • A test framework simplifies adding tests to your project.
  • Choose a framework that doesn’t get in your way and makes testing fun.
  • Coverage tools are useful to identify which parts of the code are executed with tests

Property-Based Testing


  • PBT emphasizes writing conditions that test examples should satisfy
  • Actual test cases are auto-generated.
  • “Shrinking” zeroes in on the minimal examples that trigger failure.

Testing and Design


Mocking and Isolation


Refactoring Legacy Code


  • Testing long methods is difficult since you can’t pinpoint a few lines of logic.
  • Testable code is also good code!
  • Changing code without tests can be dangerous. Work slowly and carefully making only the simplest changes first.
  • Write tests with an adversarial viewpoint.
  • Keep tests DRY, fixtures and parameter can help.

Brittle Tests and Bugs


  • Changing a lot of test code for minor features can indicate your tests are not DRY and heavily coupled.
  • Do NOT invent a Swiss-army knife! TDD helps keep you focused on iterative, essential development.
  • Testing a module’s interface focuses tests on what a user would typically observe. You don’t have to change as many tests when internal change.

Co-Authoring with LLMs: AI and TDD


Summary and Next Steps