I'm a bit unsure with slide #12. In my opinion, it'd be better to call p.cost as rarely as possible, i.e. three times on this slide instead of six times. There are two reasons which come into my mind: first, you need to call it only once and check this stored value afterwards -> increased performance by reducing the number of function calls. My second argument is the reason why I'm insecure with critisizing the multiple calls of p.cost. On the one hand, Python is not a pure language, so we cannot be really sure if the method returns always the same value if we call it an arbitrary number of times. On the other hand, we live in an ideal world where we now which functions are pure and which are not (and because we are so perfect programmers, most of them are), so we also know that p.cost can be called multiple times safely.

How do you reason your decision?

Fantastic presentation. I like the progression from motivation to roll-your-own to the standard library. The 'under the covers' slides are great too. There's nothing magical going on, and it's nice to be reminded of the fact...

Is there any chance your talk will be taped? I'd love to show it at work -- either that or give the talk using your slides (assuming that's okay with you).

A related coverage.py question: I like nose, but don't like to pull in dependencies unless I really have to. Now that Python 2.7/3.2 unittest has discovery built in I plan on using it instead. How does one run coverage.py when using the unittest test discovery?

PS. Slide 66 ('It works great!') has bullet points but no text. Missing content?

Looks really good, just Slide #66 is missing contents at the bullet points (Linux/chromium).

And wow, this mocking via shadowing the system call in #70 makes me really jealous, that's not working in many languages I use. Would be so convenient...

URL on last slide is also a bit too wide.

Thanks for sharing :)

@Simon: The code is that way because I was adding lines one at a time, and I didn't want adding the assert lines to change the existing lines. But I can see your point, so I'm thinking about how to change it. Also, it fits on the slide like this, and wouldn't if I assign the return value to a variable! :)

@Leon: thanks. We haven't worked out the logistics of recording the meetup talks, so it won't be.

About unittest in 2.7: You discover tests with "python -m unittest discover", so you can simply replace "python" there and use: "coverage run -m unittest discover".

Slide 66 indeed was unfinished, thanks.

http://nedbatchelder.com/text/st.html#8 misses one very important aspects of tests like doctests - they are intuitive for people without previous knowledge of testing.

@anatoly: yes, doctest is an important topic. I left it out due to time, and also because I don't like doctest.