In episode 1 of the Python Test Podcast, I listed the topics I wanted to cover, and the goals.
But I didn’t list out all of them in the show notes.
I’m posting these here to be a slightly more convenient than referring to the show notes.
I’ve made a few changes to the pytest-expect fixture plugin.
- I’ve put the plugin code on github, https://github.com/okken/pytest-expect.
- It is re-arranged to be a plugin installable with pip. Although I don’t have it in pypi yet.
- I’ve modified the code to use pytest 2.7.0 @pytest.mark.hookwrapper.
- I incorporated Bruno’s feedback from the last post to allow both assert failures and expect failures to be reported in the same test.
- There’s a tests directory to test the plugin.
There’s still lots to do. But this is a decent start.
Instead of listing any code here, go check out the pytest-expect repository on github
Also, I’ve set up a pytest-expect page. Not much there yet, but I plan on hosting the documentation for this thing there.
Previous posts in this series:
This is the first iteration that implements ‘expect’ as a fixture.
This is really the third attempt at an ‘expect()’ implementation that allows multiple failures per test.
- First attempt was a general solution that works with any test framework, but with a slightly clunky API. The main problem with it was that it required the test to call a final ‘assert_expectations()’ from the test code. If you forgot to call that function, the failures weren’t reported.
- Second attempt was a pytest plugin implementation that eliminated the need for the ‘assert_expectations()’ call in the test because it was called automatically. I wasn’t thrilled with this solution. But it works.
- In the solution I’m presenting in this post, I’m moving all of the code into one file and implementing ‘expect’ as a pytest fixture.
Occasionally referred to as Test First Development, Test First Programming is a beautiful concept that radically changed the way I approach software development.
The ideas of Test First Programming and Test Driven Development are often muddled together.
However, Test First is powerful enough to stand on it’s own.
I think it’s important to present the concepts separately.
TDD and many other agile practices build on Test First.
This isn’t just about remembering the past.
The lessons learned from Test First are still very important.