Welcome to the Guardian, Simon! I only wish I'd still be there when you started, but I'll be gone by then. :-(
Time for another London Python meetup, pre-PyCon UK 2008.
PyCon UK 2008, at which I find myself the "Session Chair Team Captain", God help them. Given how rubbish I am at organizing London Python, I do hope I can pick my game up a bit.
My Mac died again a month or so ago - another HDD failure. Not a problem, I thought - new disk, restore from Time Machine, sorted.
Only my Time Machine backup disk had been plugged in to my Mac when it died, which is at least as bad as pulling the plug without unmounting. The backup disk wouldn't mount. Dash it, I thought.
All in all, though, I'm surprised how little I lost:
What did I lose?
Lesson learned - Time Machine is great for convenience, but don't trust it as your only backup mechanism. If it wasn't for those DVD-R backups I'd taken a few months back, i'd have lost far more than I have.
Given that I'm speaking on Python mocking shortly, I thought I'd better dig through my accumulated bookmarks and see what I'm missing.
PyMock is what I've been using up till now. It's heavily inspired by EasyMock, a mocking style I'm used to. It's pretty good, really. The docs really could be better, and the failure messages are not very helpful, but it does the job.
But then I found Mox. Superficially, it's very similar to PyMock. It's also based on EasyMock. But wherever Mox does differ from PyMock, it's better.
It's much better documented than PyDoc, and has more meaningful, helpful failure messages. I think it's has more functionality, too, with some nice comparators, side effects and callbacks. StubOutWithMock()
is nice too. But it's possible that PyMock has all of this - given the documentation, it's hard to tell.
Mox will warn you if you call a method on a mock that the mocked class doesn't have, which is handy. It can get confused if your mocked class uses delegation, but you can always fall back to MockAnything()
. The mailing list is small but helpful.
On the downside, Mox isn't in PyPI, which is a shame. And they missed a trick not calling the documentation MoxDox. ;-)
There are many other Python mocking packages out there, too - notably pMock, a jMock style mocking library, Mock and minimock, a mocking library for the doctest unit test library.
In early development there's Mockito For Python, a port of Mockito, which will be worth keeping an eye on if Szczepan ever gets the hang of Python. ;-)
As an aside - I think we need Spamcrest!
Update: Seems there's already a Hamcrest for Python - source here.
Also - I forgot one other problem with Mox - the naming standards. One of my biggest early stumbling blocks was that my brain refused to see the the initial capital on the AndReturn()
method, and I couldn't get anything working. It's Google's internal naming standard, I gather. Yuck. I feel a patch with PEP 8 style synonyms coming on.
Via "Let's set a new standard" I discovered Goodhart's law. I've long been arguing, err, OK, ranting that the setting of targets in an organization is usually counter-productive, because people will very soon learn to game the system, meeting the targets without actually doing what the organization is supposed to be doing. Think SATs, hospital waiting lists, arrest figures, the list goes on.
It's nice to know that the effect has a name.
Dan Abel had a similar discovery recently, when he stumbled on the term Moral Hazard, an effect he'd noticed before.