DjangoCon 2011 – Testing: The Developer Strikes Back

Next up is “Testing: The Developer Strikes Back” by Sandy

“Code not tested is broken by design” – Jacob Kaplan-Moss Every programming project has unique testing needs. It’s not always easy to understand what those needs are, or how to write tests that satisfy them. One of our goals as developers is to write tests that minimize failures in production that can cost our companies time, money, resources, and in many cases, hours of sleep!

You can view Sandy’s talks at https://docs.google.com/present/view?id=0AVthC0Z3iw8DZGRrdnFzeGdfN2c5bWJ6d2Y1&hl=en_US

Updates below:

18.01

Tests don’t replace good documentation

17.59

When writing tests, pretend that you’re a user and test against what they would be doing.

17.56

How do you train your developers between “My test suite passes” and “My test suite actually tests my code”?

Make sure your developers look at the code. Break the code and see if the code still passes. Trying to break the test suite.

17.54

@sandymahalo talk over now. Fantastic speaker, answering questions now.

17.53

How to sell testing at your Django shop

  • Saves money
  • Saves development time ($$$)
  • Happier developers
  • Saves on QA time ($$$)
  • Gives you more confidence in your code

17.51

Staging environment should be identical to production (or as close as possible)

17.51

Code should not be written in such a way that it won’t work (at least in some fashion) if a certain service or infrastructure fails

17.49

Service unavailable shouldn’t mean that your site is unavailable.

17.49

Developers need to think outside of their dev instances. What happens to the code under condition X when it interacts with service Y

17.48

Fixtures are great for loading data required to bootstrap your application. ObjectCreator classes for models that change frequently.

17.47

Testing a virgin codebase:

  • Test Driven Refactoring
  • Broadly test each app. Drill down testing afterwards
  • Require unit tests for all code going forward
  • Reserve time/points to clear out “test debt”
  • Establish a good foundation to build on
  • Every bug is two bugs: One in the code that broke, and one in the test that failed to detect it
  • Implement Continuous Integration (CI) to monitor coverage

17.44

Sometimes testing can difficult because it can depend on your environment.

17.42

Make a game out of testing with coverage.py

17.41

Testing allows for faster iterations and deployments with more confidence. Less 2AM fires that you have to fix.

17.41

Tests are not “set it and forget it”. Tests always need to evolve as new functionality is added

17.40

Well-tested code is a good medium. It’s more realistic, practical and allows for a more individual “style” in the dev cycle

17.39

Test Driven Development (TDD) doesn’t really exist in real life. Deadlines, non-technical management, poor planning, competing obligations get in the way.

17.38

If the tests aren’t easy to write, your functions are too difficult. Try to refactor if possible.

17.37

“Writing tests can improve coding habits”. Smaller, more module code is testable, 200-line functions aren’t

17.36

How do I test cache?
You need to know and understand how your modified application behaves when it interacts with a cache that was generated by your application in a previous state.

17.33

Don’t take 3rd party APIs for granted. Even Facebook goes down from time to time. Have tests to cover what happens when that API is down (or changes)

17.31

http://python-mock.sourceforge.net/ can be used to mock an actual object.

17.31

Using a ObjectCreator class makes the supporting code for your test more loosely coupled and easier to write

17.29

Aggregating certain test methods that are used throughout the entire project are fine to put in a test.py at project root, just don’t put all tests in there.

17.28

Example project layout

project/
    app/
        tests/

17.26

Have multiple test files, don’t aggregate all tests into a monolithic file named test.py

17.25

Separate code and service/infrastructure testing.

17.25

Separation should exist between the testing of:

  • Business logic
  • Datastores
  • 3rd party APIs

17.24

Within a Django project each app needs its own test module.

17.24

What is “Unit testing”

A method by which individual units of source code that are tested to determine if they are fit for use.

17.23

“Testing: It’s hard to do (right)”. Tests are living code and evolve over time

17.22

Ah, its Sandy Strong (@sandymahalo) from PyLadies

17.20

First slide looks like it’s straight from reddit.com. Awesome

17.18

Sandy taking the stage. No idea what her last name is.