O'Reilly logo

Test-Driven Development with Python by Harry J.W. Percival

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Appendix F. Cheat Sheet

By popular demand, this “cheat sheet” is loosely based on the little 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, 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 1, Chapter 2, Chapter 3

The Basic TDD Workflow

  • Double-loop TDD (Figure F-1)
  • Red, Green, Refactor
  • Trianglulation
  • The scratchpad
  • “3 Strikes and Refactor”
  • “Working State to Working State”
  • “YAGNI”
A flowchart showing functional tests as the overall cycle
Figure F-1. The TDD process with Functional and Unit tests

Relevant chapters: Chapter 4, Chapter 5, Chapter 6

Moving Beyond dev-only Testing

  • Start system testing early. Ensure your components work together: web server, static content, database.
  • Build a staging environment to match your production environment, and run your FT suite against it.
  • Automate your staging and production environments:

    • PaaS vs. VPS
    • Fabric
    • Configuration management (Chef, Puppett, Salt, Ansible)
    • Vagrant
  • Think through deployment pain points: the database, static files, dependencies, how to customise settings, etc.
  • 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: Chapter 8, Chapter 9, Chapter 20, Appendix C

General Testing Best Practices

  • Each test should test one thing.
  • One test file per application code source file.
  • Consider at least a placeholder test for every function and class, no matter how simple.
  • “Don’t test constants”.
  • Try to test behaviour rather than implementation.
  • Try to think beyond the charmed path through the code, and think through edge cases and error cases.

Relevant chapters: Chapter 4, Chapter 10, Chapter 11

Selenium/Functional Testing Best Practices

  • Use explicit rather than implicit waits, and the interaction/wait pattern.
  • Avoid duplication of test code—helper methods in base class, or Page pattern are one way to go.
  • Avoid double-testing functionality. If you have a test that covers a time-consuming process (eg, 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 17, Chapter 20, Chapter 21

Outside-In, Test Isolation Versus Integrated Tests, and Mocking

Be reminded of the reason we write tests in the first place:

  • To ensure correctness, and prevent regressions
  • To help us to write clean, maintainable code
  • To enable a fast, productive workflow

And with those objectives in mind, think of different types of tests, and the tradeoffs between them:

Functional tests
  • Provide the best guarantee that your application really works correctly, from the point of view of the user.
  • But: it’s a slower feedback cycle,
  • And they don’t necessarily help you write clean code.
Integrated tests (reliant on, eg, the ORM or the Django Test Client)
  • Are quick to write,
  • Easy to understand,
  • Will warn you of any integration issues,
  • But may not always drive good design (that’s up to you!).
  • And are usually slower than isolated tests.
Isolated (“mocky”) tests
  • These involve the most hard work.
  • They can be harder to read and understand,
  • But: these are the best ones for guiding you towards better design.
  • And they run the fastest.

If you do find yourself writing tests with lots of mocks, and they feel painful, remember “listen to your tests”—ugly, mocky tests may be trying to tell you that your code could be simplified.

Relevant chapters: Chapter 18, Chapter 19, Chapter 22

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required