[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2777: modernize tests, use "mock"

[Tahoe-LAFS]

#2777: modernize tests, use "mock"
------------------------+-----------------------
     Reporter:  warner  |      Owner:
         Type:  task    |     Status:  new
     Priority:  minor   |  Milestone:  undecided
    Component:  code    |    Version:  1.11.0
   Resolution:          |   Keywords:
Launchpad Bug:          |
------------------------+-----------------------

Comment (by meejah):

 It also might be fruitful to look at changing at least some of the *MixIn
 "helper" classes to be 'just' helper *methods* instead.

 By which I mean that if a test-suite wants a particular helper, instead of
 inheriting from the MixIn and using `self.{various state}` idioms, it
 might be better to have a "create_whatever_helper" and assign it to
 `self.whatever` in the `setUp` of any test-suites that need them.

 For example, to use the "no network" test helper, you currently:

  - subclass `GridTestMixin`
  - make sure you called its `setUp` properly
  - call `self.set_up_grid` at some point (but after the above)
  - access the grid state via `self.g` and friends (which are set in
 `set_up_grid`) or any of the dozen methods added to `self` by the mix-in

 Instead, it might be more-clear to take the functionality of `set_up_grid`
 and make it a bare method that creates you some helper object off of which
 hang any interesting helper methods for the test. Something like:

  - change `class GridTestMixin` into `class NoNetworkGrid`
  - turn `set_up_grid` into a bare factory method that creates, initializes
 and returns a `NoNetworkGrid` (could be async if needed)
  - ...keep all the other state + helper functions it already has

 Then, to use this a test-suite would:
  - do something like `self.grid = create_no_network_grid()` in its `setUp`
  - access + change grid state via `self.grid.*`

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2777#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage