I try not to make a habit of reviewing technical books. I own more than my fair share of technical books, and I’ve been involved in publishing and even wrote a book myself. Most technical books, on the whole, are pretty bad.
So, there’s Disclaimer 1: you know the mindset I’m starting with. I’m a bit critical of tech books, publishers, and occasionally even authors (but usually publishers).
Most book reviews are also biased for one reason or another, and I hate to be lumped into a pool of “book reviewers” that I have nothing to do with. A great many of them are astroturfers trading favors with the publishing company or just cheerleading in general when in fact they’ve never even seen the book.
So, Disclaimer 2:
I requested a free “review copy” of Python Testing: Beginner’s Guide, specifically because I wanted to pick up some of the techniques I expected I’d find in the book on a project I was working on in the moment. The timing really could not have been better. They requested that I post a review, and I said that I would — “good or bad”.
So let’s talk about the book!
Things That Impressed Me
It’s an eBook
I got an eBook from Packt Publishing and dove into the book almost immediately, without having to wait behind some annoying old lady griping incessantly to an equally annoying emo-hipster wannabe behind the counter at a bookstore who inevitably can’t do whatever it is this old lady wants. We’ve all been there. eBooks rock. I think some publishers do better than others where eBooks are concerned, but that’s a tale for another day. I was happy I could at least get an eBook (PDF).
This book’s author and/or editor appears to have taken great pains to insure that the Python code listings do not break across pages in strange places. Python, as a language, isn’t exactly custom made for book layouts: since there are no brackets and only indentation is used to denote the scope of a given statement, if you have trouble telling how far a line on one page is indented relative to the line on the next page, it can be tough. Especially on newbies, but in some cases just as much for experienced coders. Anyway, I could not find a single instance of this issue in this book, and I was really impressed by that.
Ok, pretty much all example scenarios given by an author to provide some context to illustrate a concept are contrived. That doesn’t bother me. What does bother me is that most authors just shrug and say “this is how it is, and how it will always be, forever, so it doesn’t matter that my example scenario completely fails to engage the reader”. This author didn’t do that. He came up with example scenarios that were pretty much contrived, but he lent to them a “slice of life” that made them a billion times more interesting to actually read through, and I did!
I often just skim the explanation of the example scenario because most of them are so much alike, and are such null operations, that the pages spent explaining “Stupidest Program You’ll Ever Write: Take 1,112,039” are a complete waste of space. But I read these, and really enjoyed them. I mean really, who sits down to explain Python Testing and says to themselves “I know! We’ll write a PID controller!”. The answer is Daniel Arbuckle, this book’s author.
There isn’t one in this book, and I’m happy about that. If you don’t know the language, you shouldn’t be reading a book devoted to testing code you don’t know how to write. That said, beginner books on languages could (and perhaps should, at least to an extent) teach by starting with testing, or at least integrate testing into the learning. Anyway, this book skips those really mind-numbing first three chapters about who Guido is and how ‘Python’ is not a reptilian reference. The author dives right into the meat of the matter. Very good.
I don’t know Daniel Arbuckle. Never met him. Never heard of him. Don’t think he wrote any other books that I know of. But the guy can really write. There’s only so much an editor or publisher can do for you in terms of your voice as an author. At some point, it’s just you, the author, telling a story to the reader, and efforts by the publisher to make it “more this” or “more that” just become really obvious and distracting.
Daniel Arbuckle writes like he really is excited to be talking to you about Python testing. He has interesting things to say, he writes in a good-natured, friendly, engaging tone, and he is thoughtful about his audience of beginners throughout. If you know Python, but are a little bewildered by testing, you’re going to understand everything Arbuckle says, and you’re going to have lots of light bulb moments. The shocking bit to me was this this is a guy who has a PhD in Computer Science, and a lot of PhD’s (in any topic area) write everything as if they’re writing their thesis. A thesis is not typically written to engage newcomers and non-academics.
At the start of this book, my experience with testing consisted of historically writing some really ugly code to do what amounts to functional testing, and I had, over the past year, taken to writing proper unit tests for some of my less-complicated projects. More complicated projects involving threading/multiprocessing with networked queues, databases and remote APIs? Well, I was trying to organize my code to make it more testable, but it impacted my development timeline to such an extent that testing took a back seat to deadlines, sadly (I’m the only person I know who has an actual, genuine *interest* in code quality).
At the end of this book, I still have some of the same problems, of course, but I am extremely excited and far more confident that I *will* eventually be able to work this into my breakneck development pace and have it be effective. I have a pretty firm grasp of both unittest and doctest, in addition to Nose, and one thing I *didn’t* have going in was an understanding that doctest is actually perfectly suited for testing in some areas where unittest might be a little overkill, harder to do, etc.
I also was able to put my own experiences with testing into perspective, and I was able to apply some things I learned pretty much right away.
Things That Did Not Impress Me
Here’s the thing, 99% of all tech book indexes are terrible, because 99% of all books have a computer-generated index that the author never sees until the published book reaches his doorstep. The books with really good indexes utilize input from the author, and I use the quality of an index as a sign of the quality of the publisher, the editor, their ability to manage the hectic process that is the creation of a book, and their commitment to quality.
This book’s index is not nearly the worst I’ve seen, but it’s pretty bad. If you’ve never noticed that the indexes of several books you own are terrible, you can probably disregard this.
There’s the author, and then there’s the editor. When you’re looking for authors, you’re less concerned with whether they can write in accordance with the Chicago Style Manual and more interested in whether they can convey ideas to an audience using words. It’s the job of the publisher’s staff to deal with grammatical problems and issues with punctuation. So when you see bad grammar and punctuation (or even spelling) in a technical book, look to the publisher, not the author. The publisher’s job is to make the author look like a rock star. If you’re not thinking that, it’s not the author’s fault.
As it turns out, one of two things seems to have happened in this book:
- Daniel Arbuckle didn’t major in English, so his use of commas is off, and the editors failed to pick up on that (like, a lot), or
- The publisher hired a summer intern from the local high school to do Mr. Arbuckle the favor of inserting commas wherever she thought they looked pretty.
I don’t know which one of these things happened, but the misuse of punctuation in this book really bugged me.
Before I read this book, I perceived mocking objects as being the hardest part of testing my more complicated applications. After reading this book, I still feel that way.
Unlike Arbuckle’s coverage of both unittest and doctest (and nose) for performing basic unit tests, he only covers one mocking library/framework: Python Mocker. I was glad to go through the exercise, because it forced me to sit down and do things with a record/playback style framework, but I still feel like this style of framework just does not fit my brain. I really wish the book had one more chapter about object mocking using a library that did not use that model. There are a few out there. One I’ve found that looks good (if I could ever get time to dig into it) is Michael Foord’s Mock, which uses an ‘action/assertion’ model, much like the rest of the testing tools outside of mocking frameworks.
If you know Python, and you’re not testing yet, I strongly recommend this book to get you started. It covers unittest, doctest, nose, twill; the differences between unit testing, functional testing and integration testing; testing web sites; and lots of other stuff. It also has a ‘catch-all’ chapter that talks about coverage.py, installing nose as a post-commit hook to every VCS under the sun, etc.
I’m confident that you’ll find this book a useful introduction to the world of Python testing, and that it will equip you with the knowledge of both tools and concepts you’ll need to go off on your own and solve as yet unforeseen testing issues you might come across.