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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
