selftest performance: landing our code faster and developing quicker.

[Robert Collins]

On Mon, 2009-08-31 at 14:59 +1000, Martin Pool wrote:

> What I am suggesting is generally avoiding writing tests that use
> dummy implementations of real classes - mock objects etc.  Only do
> that when the real implementation would be unreasonably expensive or
> difficult to use.

I dislike [loath, fear, hate] 'Stub' and 'Mock' objects, because they so
very very easily lead to interface skew. I still use them, but with
caution and unease.

However, I love "Test Doubles". As long as they really are a double,
tested to behave to the same contract as that which they replace.

I wrote http://people.canonical.com/~robertc/interfaceverification.txt
some years ago about this. Its not very compelling as currently written.

For our purposes, as a for instance, CHKRepository compresses and
decompresses huge amounts of data during a bzr selftest run; doing that
doesn't add a lot of coverage (!citation, I know. We'll figure that
out), but does take a lot of time.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090831/1fe4927d/attachment-0002.pgp