Getting Started with Automated Testing¶

Date:	2013-03-16
Speaker:	Carl Meyer
Slides:	http://oddbird.net/start-testing-preso

What is it?¶

gitrecs.py
- similarity() - Return similarity score for two users
Testing things manually gets old fast.
- Updating your tests with your revisions gets older faster.
- Repetitive and boring... Therefore you skip them.
- Not easily-reproducable
- Error-prone
... And you ship broken code because it’s not fully tested

test_gitrecs.py
- from gitrecs import similarity
assert similarity(blah1, blah2) == expected_value
Got ZeroDivisionError
- New test: assert similarity({}, {}) == 0.0
pytest - Test runner
- Knows how to discover & run test (if name is test_foo.py

So you knw when your code is broken.
Help later devs grok your code.
Improve the design of your code.
Testing things that rely on network information is hard
- You must fake it! (Mock objects with boilerplated data?)
- These tests are less clear
Testable code is maintainable
- The less a function knows about the world...
- The more robust it is against changes
- See: Principal of Least Knowledge
- Therefore: The less of the world you have to setup to test it

Doctest is not recommended
- Fragile
- No isolation
- Harder to maintain
- Good for testing your documentation, but that’s it!

Codebase with out test? (cough Trigger)
- Probably not structured for tests. Oh, bother.
Start /w system tests.
Use code coverage as a metric for testable areas.
- pip install coverage