[tahoe-lafs-trac-stream] [tahoe-lafs] #20: unit tests take too long

[tahoe-lafs]

#20: unit tests take too long
------------------------+------------------------------
     Reporter:  zooko   |      Owner:  somebody
         Type:  defect  |     Status:  reopened
     Priority:  major   |  Milestone:  eventually
    Component:  code    |    Version:
   Resolution:          |   Keywords:  test performance
Launchpad Bug:          |
------------------------+------------------------------

Comment (by warner):

 FYI, on my work laptop (2010 !MacBookPro, with OS-X "Snow Leopard"
 Filevault non-FDE encrypted home directory), the full test suite (current
 git master, 8aa690b) takes 27m48s to run, of which 7m23s is "user" and
 17m19s is "sys", and leaves 233MiB in {{{_trial_temp}}} (of which 118MiB
 is {{{allmydata.test.test_mutable}}}, 54MiB is {{{cli}}}, and 5-10MiB are
 used by {{{system}}}, {{{repairer}}}, {{{dirnode}}}, {{{test_upload}}},
 {{{test_download}}}, {{{hung_server}}}, and {{{test_encode}}}).

 That feels like an awful lot of data being generated. I'd start by looking
 at test_mutable and seeing if we can get rid of most of the k=N=255 cases.
 We probably need to keep one of them to exercise that end of the encoding
 spectrum, but I really doubt we need to do it for every single
 test_mutable case.

 I'd also walk though the tests that upload data and look at the filesizes
 they're using. Many are casually creating 10MB files, resulting in 30MB of
 shares. We really don't need to cover more than a few segments, so 1MB
 should be plenty, and in most cases we should be able to lower the min-
 segment-size to cover a multi-segment file with just a few kB.

 I'd also look into moving most tests to use the common !NoNetworkGrid
 class, and make sure that it's using fake server connections to avoid the
 SSL spinup time (except for test_system, of course, which needs to
 exercise the SSL connections too). We have about half a dozen fake-server
 classes in the test suite, partially because I was too lazy to improve an
 existing one and decided to create new ones instead. So there's probably
 some cleanup there that would help.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/20#comment:19>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage