Note
Sandy really, really, really rocked this talk
by Sandy Strong
- Been doing Django since fall of 2009
- Pyladies co-founder
- Delegate responsibilitiues correctly
- wont always get it right first time
- Presents reasons for refactoring
- increases stability because you can test updates and patches
- A unit is the smallest possible part of an application
- Integration tests the whole and is often built out of unit tests
Each class, method, and function should have its own test
Starting Django test.py files are limited
Organize however you want
Maintain consistency in your test patterns
Separate your tests between models, views, and hitting other services
- keep things simple
- easy to understand tests
Note
I love this pattern and use it myself!
Create test modules following the same file layout as your project
Have as few root test utils as possible
- Use it sparingly
- just a few simple helper functions!
Your tests should copy the model/view/whatever tightly
- Mock your data by using the ORM or whatever persistence your system uses
- Better than fixtures because mocking your objects this way means you are doing an addition ORM test
- The mock library is supposed to be good
- Testing third-party libraries should be separate from other unit tests
- Third party APIs go down. Even the big ones.
- Mock 3rd party API responses
- Means you can continue to work when Facebook, Google, et al go down
- Very hard
- I tend to blow away the cache in a tearDown method
- Her issues are beyond mine. Sandy rocks!
Small functions can be tested. 200 lines functions cannot
Write more tests
- Find good test patterns
- Functions should perform a single function
- Units of code should be true to the definition
- Step 1 - Write your tests
- Step 2 - Then write the code
Note
I’ve done it for short periods.
- More realistic
- More practical
- Allows for a more individual style in coding
- webhooks tests to block code that isn’t test
- coverage.py makes it a game
- Public shaming!
- Difficult areas to test because behavior is driven upon environment
- Some code doesn’t always work the way you want because people don’t script/document things out
- You may find yourself faced with a project without tests
- Set a pattern for tests, establish a framework follow it and get the team on board
- Smaller tighter tests really help
- Jenkins (continuous integration) is critical
- Test Debt is part of Technical debt
- Enforce the rule that All future code MUST have tests
- Developers need to think outside the box - their local machine is not the same as Staging/Production
- Service unavailable should not be an unavailable site
- Search. 3rd party API, Cache
- Test your dependencies on these things when they are shut down
- This way your site doesn’t just die
- No one gets staging environments that match production
- Run SOLR and RabbitMQ on staging environments
- Don’t overdo logging as it will slow everything down
- coverage
- nose
- one-more
- Pretty coverage charts
- Code not tested is broken by design
- Saves money when you have problems
- Makes it easier to add features
- Happier developers
- If someone breaks a test pattern and won’t fix it go back and make their tests follow the pattern
- Interesting to see that Sandy is into Behavior Driven Development