Archive for June, 2011

Python Testing Cookbook

I blogged previously that I was having a look at the Python Testing Cookbook courtesy of the eager marketeers at Packt Publishing. Well I’ve finished reading it — in installments on the Tube — and I think I’ve come to a conclusion.

The short version is: I’m not mad about the layout; it’s not entirely what I expected from a Cookbook; but I think it does what it does very well.

Since I’m overall positive, I’ll just pick up on the very slight negatives first. In a previous Packt review I commented (adversely) on the style of the layout and so on, and I’m afraid that it hasn’t really changed. Obviously, this is somewhat subjective, but I can’t be the only person who’s subconsciously affected by the font and layout choice. (Bear in mind that I was reading it via PDF which may make a difference). To be clear: it’s not awful; it’s not even bad; it’s just suboptimal.

The other slight negative is hardly a negative at all: that the “recipes” in this cookbook are far broader — in some cases, chapter-length — than I’d expected. Subjective expectation, to be sure. But I was a very little bit surprised.

Ok, that’s the downsides. Now the upsides:

* Nice division of chapters
* The right pacing
* Pretty much one example used throughout
* “Why didn’t you do this?” question sections
* Good re-use or alternative use of previous examples or approaches
* Interesting spread and combination of toolsets

The chapter divisions are: unittest, nose, doctest, BDD, UAT, CI, coverage, load-testing, good habits. In broad terms, each chapter builds on previous ones, but thanks to the reuse of the a simple shopping cart example, repeated in nearly every chapter, you can take a chapter on its own without too much difficulty. In addition, different chapters sometimes offer alternative approaches to the same problem when it makes sense to illustrate one point rather than another. One chapter, for example, walks you through creating a nose plugin to show how to do it; the next chapter introduces you to a ready-made one since the focus of that chapter is not nose plugins.

And that brings me to the variety of toolkits & modules mentioned throughout the text. This is not a book which simply uses stdlib code to perform various tasks (which I had rather thought it might be when I started). It introduces the ideas mentioned in the paragraph above. And puts forward Python modules (such as nose or mock) or external tools (such as Hudson / Jenkins or TeamCity) as best-of-breed or useful tools.

One final point which really put the icing on the cake is the occasional introduction of pull-out sections answering the very question which was occurring to me as a reader: “Why didn’t you use this technique here?” or “How is this different from that?”. Perhaps it’s just me, but I find this smoothes my progress through a book considerably which otherwise would be (mentally) jarred by my wondering “Now why did he do that?”.

I can’t but recommend this book. There’s a sample chapter here if you want to have sniff. As a final note, it’s very slightly unfortunate that the timing of its production precluded the author from picking up on Michael Foord’s magnificent work in producing unittest2 / unittest for 2.7 & 3.2. Perhaps there’s a “missing chapter” opportunity in there for someone…

Python Testing Cookbook - having a look

Thanks to the energetic folks in the Packt Publishing Marketing department, I’m currently looking at the Python Testing Cookbook with Python Web Development waiting in the wings. The copies I have are PDFs which are never my favourite, so I end up printing chunks out to read on the train or elsewhere, but it’s great to get to read other people’s insights and ideas. I’m about halfway through PTC so look out for a review soonish.

Python3 support…?

Brian Jones, co-author of the upcoming edition of the Python Cookbook has just tweeted, asking why anyone would release a new module now without testing for Python 3.

I sympathise, but for me the simple answer would be: because Python 3 support doesn’t solve a problem I have. It’s one more hurdle to leap over in terms of developing, documenting and testing software. And if you’re still using 2.x for production purposes then you don’t need 3.x. Other users might, but there’s little enough time to scratch one’s own itches let alone scratch other people’s for them.

On the plus side, I’m trying to keep my own modules Python3-friendly, running Python 2.x with the -3 flag, making a few decisions which I know will help 2to3 out (or will remove the need to use it altogether). But at the end of the day, the things I write need to work for the environment I have — which at the moment is 2.7 — and not for the environment I’d like other people to be running.

[UPDATE: Thanks to Mike Driscoll for pointing out how to link to a tweet].