← Back to team overview

launchpad-dev team mailing list archive

Re: Phasing in the Architecture Design Metrics into our reviews

 

On Monday 13 December 2010 17:15:50 Aaron Bentley wrote:
> On 10-12-13 11:05 AM, Julian Edwards wrote:
> > 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.
> 
> I think that we'll have a better idea if we articulate our goals.  I
> think that reasonable people could disagree over whether a 1-second test
> is too slow.

Most reasonable people will use common sense here, and only unreasonable 
people will disagree.  Or more to the point, I'd expect the people involved to 
have a short, rational discussion and come to a quick, mature, informed 
decision.

> One way of looking at this is to say that we'd like the test suite to
> complete in half an hour.  We currently have 11454 tests, so that means
> we'd like our tests to take .16 seconds on average.  From this
> perspective, a 1-second test is *way* too slow.
> 
> > 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.
> 
> Those are all great suggestions for writing tests, but they don't
> directly apply to a reviewer who is trying to asses whether tests are
> too slow.

I'm not sure if you're joking or not here.  These are all points that a 
reviewer can apply when reviewing test code to see if it could be quicker.




Follow ups

References