buy the book ribbon

Appendix F: Cheat Sheet

By popular demand, this "cheat sheet" is loosely based on the recap/summary boxes from the end of each chapter. The idea is to provide a few reminders, and links to the chapters where you can find out more to jog your memory. I hope you find it useful!

Initial Project Setup

  • Start with a user story and map it to a first functional test.

  • Pick a test framework—unittest is fine, and options like py.test, nose, or Green can also offer some advantages.

  • Run the functional test and see your first expected failure.

  • Pick a web framework such as Django, and find out how to run unit tests against it.

  • Create your first unit test to address the current FT failure, and see it fail.

  • Do your first commit to a VCS like Git.

Relevant chapters: [chapter_01], [chapter_02_unittest], [chapter_03_unit_test_first_view].

The Basic TDD Workflow: Red/Green/Refactor

  • Red, Green, Refactor

  • Double-loop TDD (Double-loop TDD)

  • Triangulation

  • The scratchpad

  • "3 Strikes and Refactor"

  • "Working State to Working State"

  • "YAGNI"

An inner red/green/refactor loop surrounded by an outer red/green of FTs
Figure 1. Double-loop TDD

Relevant chapters: [chapter_04_philosophy_and_refactoring], [chapter_05_post_and_database], [chapter_07_working_incrementally].

Moving Beyond Dev-Only Testing

  • Start system testing early. Ensure your components work together: web server, static content, database.

  • Build a production environment early, and automate deployment to it.

    • PaaS versus VPS

    • Docker

    • Ansible versus Terraform

  • Think through deployment pain points: the database, static files, dependencies, how to customise settings, and so on.

  • Build a CI server as soon as possible, so that you don’t have to rely on self-discipline to see the tests run.

Relevant chapters: [part2], [chapter_25_CI].

General Testing Best Practices

  • Each test should test one thing.

  • Test behaviour rather than implementation.

  • "Don’t test constants".

  • Try to think beyond the charmed path through the code, and think through edge cases and error cases.

  • Balance the "test desiderata".

Relevant chapters: [chapter_04_philosophy_and_refactoring], [chapter_14_database_layer_validation], [chapter_15_simple_form], [chapter_27_hot_lava].

Selenium/Functional Testing Best Practices

  • Use explicit rather than implicit waits, and the interaction/wait pattern.

  • Avoid duplication of test code—​helper methods in a base class and the page pattern are possible solutions.

  • Avoid double-testing functionality. If you have a test that covers a time-consuming process (e.g., login), consider ways of skipping it in other tests (but be aware of unexpected interactions between seemingly unrelated bits of functionality).

  • Look into BDD tools as another way of structuring your FTs.

Relevant chapters: [chapter_23_debugging_prod], [chapter_25_CI], [chapter_26_page_pattern].

Outside-In

Default to working outside-in. Use double-loop TDD to drive your development, start at the UI/outside layers, and work your way down to the infrastructure layers. This helps ensure that you write only the code you need, and flushes out integration issues early.

Relevant chapter: [chapter_24_outside_in].

The Test Pyramid

Be aware that integration tests will get slower and slower over time. Find ways to shift the bulk of your testing to unit tests as your project grows in size and complexity.

Relevant chapter: [chapter_27_hot_lava].

Comments