Interview with Harry Percival
If you develop and/or test web applications, especially django, you will probably enjoy this episode.
Rough outline of what we talk about:
Part 1 (first 20 minutes)
- Intro to Harry Percival, his background and story of how he got into TDD and ended up writing a book
- Hinting of perhaps a follow up tutorial to cover some more intermediate level topics.
- Testing django apps has some commonalities with testing flask, web2py, bottle, but djanogo does have some built in helpers.
- Comparing using unittest and pytest with applicability to testing django projects.
- Benefits of pytest treatment of asserts.
- Fixtures in pytest and how they seem magical. (and a reminder that pytest supports xUnit style setup/teardown).
- The meaning of “fixtures” as “data preparation” vs “setup/teardown”.
- Levels of testing, the test pyramid, end to end, functional, and unit testing.
- Some examples of very high level system testing using unittest and/or pytest.
- Where you put your tests in a django project and apps.
- Separating your functional testing from django app structure.
- Functional end to end testing with selenium.
- The django test client for middle level tests.
- Lower level test that perhaps don’t use django test client, or avoid the database.
- Business logic or algorithm tests might be candidates for isolated unit tests.
Part 2 (after the 20 minute mark)
- test isolation
- testing a specific unit of code
- perhaps only one function or method in isolation of rest of system
- mocking or dependency injection
- don’t have dependencies for a function
- some logic examples where this work
- django and isolated unit tests
- test isolation might not make sense for web applications
- apps might be thin layers around a database
- effort of isolation might not be worth it
- django philosophy of “framework for perfectionists with deadlines”
- view functions make a good place to test between the Internet and the models/database
- larger projects might need testing at more levels, like around the business logic
- unit tests vs integration tests
- bugs are in the interactions or interfaces or bad assumptions
- revision control, history, and continuous integration services often help detect faulty code just as much as test isolation.
- integration tests are often the most helpful because that’s often where the difficult to find failures occur.
- pushing dependencies into fixtures can help with test isolation as well, by having dependency failures result in an Error and not a Failure.
- Harry recommends a talk by Gary Bernhardt, Boundaries.
- Testing done by the development team without an external QA
- Double loop TDD: Functional test first, then unit tests
- Spikes: investigations without tests
- Harry’s experience with having a freely available web version of a book that is also intended to be sold.
I might have been a bit down on unit tests vs functional tests in that “unit tests never fail comment”.
Not true at all, particularly as we’ve just been thru upgrading django on our core system, and the unit tests *really* saved our bacon on that one…
- Test-Driven Development with Python – Harry’s book that I’m reading right now and highly recommend.
- Obey the Testing Goat – Harry’s site dedicated to the book and related posts.
- Python Testing with unittest, nose, pytest
- Support the show
- Gary Bernhardt’s talk, Boundaries talk including a discussion of “Functional Core, Imperative Shell”.
- Above link is Gary’s site. Video is also on youtube
- Test-Driven Development with Python
- Support the show
There is not a transcript available for this episode.
If you’d like to have transcripts, please consider supporting the show.
I do have a goal on Patreon tied to getting transcripts done..