Getting started testing

Sunday 17 July 2011

This Wednesday the 20th, I'm speaking at the Boston Python Meetup: Getting Started Testing your Python. Please do come if you're in town. My goal will be to provide a totally from-scratch introduction to how to test Python code, in two hours, with time for questions.

I think I may have too much to say, though. The presentation itself is available for review. It could use another (hundred) pair of eyes. If you have any suggestions about what I should leave out, what I need to add in, what I've done completely wrong, and so on, let me know, either in a comment here, or in an email.

Thanks.

Comments

[gravatar]
Simon Liedtke 6:40 PM on 17 Jul 2011

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?

[gravatar]
Leon Matthews 11:28 PM on 17 Jul 2011

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?

[gravatar]
Florian 12:50 AM on 18 Jul 2011

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 :)

[gravatar]
Ned Batchelder 9:05 PM on 19 Jul 2011

@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! :)

[gravatar]
Ned Batchelder 9:08 PM on 19 Jul 2011

@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.

[gravatar]
anatoly techtonik 8:36 AM on 21 Jul 2011

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.

[gravatar]
Ned Batchelder 9:46 AM on 21 Jul 2011

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

Add a comment:

name
email
Ignore this:
not displayed and no spam.
Leave this empty:
www
not searched.
 
Name and either email or www are required.
Don't put anything here:
Leave this empty:
URLs auto-link and some tags are allowed: <a><b><i><p><br><pre>.