I seem to find myself signed up to talk at PyCon UK on Mock Testing with Python. Eeeek!

Luckily, this evening I'll be at London Geek Night: Mocking with Java, so I should be able to pick up some tips.

Fuzzyman has a new mocking library for Python, which he presents in Mocking, Patching, Stubbing: all that Stuff.

Michael takes issue with Martin Fowler's Mocks Aren't Stubs; specifically where he defines mocks as objects pre-programmed with expectations which form a specification of the calls they are expected to receive. Michael's mocks are not pre-programmed with expectations - his expectations are defined after the test execution.

Now, to me, this is a trivial distinction - the important difference between a stub and a mock is in the existence of expectations. Whether the expectations are defined before or after the text execution is not crucial - it's still a mock.

It does matter in terms or usability, of course. It feels more natural to Michael to define his expectations after the test object is exercised, along with his assertions. For me, I have to say that defining the mock object's behaviors all in one place makes sense, so both the expected method calls and any return values should defined together - and the return values have to be pre-defined. We are using EasyMock here at GU (along with the Hamcrest constraints library) and I like it just fine. But that's more a matter of taste than anything else.

Julian and I have been asked to put together some unit and functional test coverage figures. We've not actually been given any time in which to do it, though, so I wouldn't hold your breath.

Looks like some work was put into using Emma to provide these figures, but it's not finished.

Over in the Python world, there's been some discussion over on c.l.py about Ned Batchelder's coverage.py, which looks like a fairly nifty module.

OTOH, I think you have to be a bit careful with metrics such as those provided by these coverage tools. Ned himself points out many of the problems with taking your coverage figures at face value (though Emma's block-level approach fixes some of them).

I'd add one more issue - gaming. People can start to see good coverage figures as an end in and of themselves. If the coverage isn't at, oh, say 80%, the tests must be crap. If they are at 100%, they must be great. It's not just that the figures can be meaningless, they can actually lead people astray.

Now, for an approach to coverage testing that actually makes sure you are testing that your code does the right thing, check out Jester & Pester.

I've been trying to upgrade the version of Selenium core that we are using from the rather old 0.6 to the shiny new 0.8.2. It's turning into a bit of a slog.

Firstly the assertNoFailureOnNextAndGoto user extension that we are using to ensure that each test starts out logged out needed an upgrade, but Margo sorted that one out.

Next, we had a problem with our assertLocations. Selenium 0.6 would pass the assertion if the supplied values matched any part of the actual URL. 0.8.2 supports patterns - much superior, but the change required us to re-visit all our hundreds of tests and whack asterisks around all our asserted locations. I took over at this point to exercise a spot of regex-fu.

But now I've got a bit of a show stopper, and I'm stuck. 0.8.2 strips whitespace from type action values - which buggers things up royally if the values in question consist of Python code! I tried working around the problem by whipping up a quick user extension, but that didn't help, 'cos the whitespace has already been stripped by the time the value is passed to the function. I'm not getting any love from the Selenium forum, either.

Any suggestions from the gallery?

Update: I tried IRC, too, but there's no one there. :-( And look, see, I'm being helpful!