Summary
Django's testrunner gets you started quickly, but you soon hit your head on its limitations as your project grows. By trading it for nose, a testing framework popular in the wider Python community, we can reduce boilerplate, boost performance, and improve testing UI, with only a few lines of setting changes. Re-use your test DBs, integrate with Jenkins, split your suite into pieces, and more.
Description
- Why nose?
- Pain points with standard Django testing
- Extensibility without writing custom, uncombineable testrunner subclasses
- Rich ecosystem of helpful plugins
- django-nose
- Testing just your apps, not all the random installed stuff
- Test-selection tricks: running just failed tests, running a module, etc.
- Killing the boilerplate:
- No more imports into init
- No more class name collisions and accidental shadowing
- With all this freedom, how best should you organize your tests?
- Going 4 times faster with fixture bundling
- Troubleshooting
- Fixtures are evil
- Where do I put the factories?
- Speeding startup with test DB reuse
- Writing faster TransactionTestCases with hygienic base classes
- Background on Django's handling of TransactionTestCases
- How to improve matters
- Test-only models: what's the best practice?
- nose-progressive
- Dots considered harmful. When will my tests be done?
- Patience is for the dead. Show me my tracebacks as they happen!
- My terminal is only this big. Don't waste my space.
- Hiding pointless stack frames
- Editor round-tripping for quick debugging
- Splitting into sub-suites
- An introduction to the attr plugin
- Have some run only on CI machines, some constantly, others before checkin
- Choosing tests with regexes
- Other fun plugins
- f7u12, for when your tests get angry
- Coverage
- xunit, for your continual integration pleasure
- Profiling