launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 13 December 2010 14:53:24 Aaron Bentley wrote:
> On 10-12-13 09:45 AM, Brad Crittenden wrote:
> >> Thanks, but I'm looking for a guideline I can use as a reviewer to say
> >> "your tests are taking too long" or "your tests are astoundingly fast--
> >> please share your secrets with the mailing list".  Without numbers, I
> >> can't do that.
> > 
> > Hi Aaron,
> > 
> > Reviews are a discussion not simply enforcement of rules.  I'd have no
> > problem saying "Wow, your new test provides great coverage but seems to
> > be really slow.  Let's see if we can speed it up."
> 
> Certainly, reviews are not merely enforcement of rules.  But I can't say
> "Wow, your new test provides great coverage but seems to be really slow.
>  Let's see if we can speed it up." until I have a definition of "slow".
>  Without numbers, I can't do that.

I think most of us have a pretty good idea of what constitutes a slow test 
now, and where the time is lost in those.  I don't think you need absolute 
numbers.

The big points I think about are:

 * Favour view tests over page tests - rendering a page is slow
 * Can your test run without any layers?  i.e. are you just testing a really 
basic piece of code that doesn't need the database, librarian etc., and can 
you refactor your code and tests so that most of your tests can run layerless?
 * Look at what code you are testing and make sure you're testing the absolute 
minimum of what is necessary.  For example, many of the Soyuz tests are 
utterly stupid in that they upload a whole package (which is dog slow) just to 
test a small aspect of the upload processor.  That's something we can make 
much faster by testing only the appropriate piece of code.