#2500 closed defect (fixed)

teach magic-folder unit tests to time travel

Reported by: dawuud Owned by: daira
Priority: normal Milestone: undecided
Component: code-frontend-magic-folder Version: 1.10.1
Keywords: otf-magic-folder-objective4 Cc: daira
Launchpad Bug:

Description

It makes sense to have our unit tests fast forward the clock to avoiding blocking on sleep; and also we really shouldn't be using a global reactor.

https://twistedmatrix.com/documents/current/core/development/policy/test-standard.html

"""Most unit tests should also avoid waiting for real time to pass. Unit tests which construct and advance a twisted.internet.task.Clock are fast and deterministic."""

and

"""Since unit tests are avoiding real I/O and real time, they can usually avoid using a real reactor. The only exceptions to this are unit tests for a real reactor implementation."""

Change History (10)

comment:1 Changed at 2015-09-08T15:54:46Z by daira

We can't avoid using a real reactor for the magic folder tests, because they make use of the real web API over loopback HTTP. There is already provision for passing a Clock to the constructors for things that have timeouts/delays; the tests just need to be changed to use that.

Last edited at 2015-09-08T15:55:17Z by daira (previous) (diff)

comment:2 Changed at 2015-09-17T13:14:47Z by dawuud

I'd like to report minor progress here in my dev branch: https://github.com/david415/tahoe-lafs/tree/2500.unit-test-clock-fast.0

  • Here I've taught the magic-folder class to accept a clock variable which is then

used internally for deferLater calls...

  • unsuccessfully taught test_alice_bob to use it's own clock... but there's some buggy destructor code that we think prevents this from working properly

comment:3 Changed at 2015-09-21T08:56:36Z by dawuud

Switching efforts to this dev branch that contains newer code from https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1710#comment:30

dev branch here: https://github.com/david415/tahoe-lafs/tree/2500.unit-test-clock-fast.2

test_alice_bob still fails...

comment:4 Changed at 2015-09-21T10:19:03Z by dawuud

the MockTest.test_alice_bob fixed here: https://github.com/david415/tahoe-lafs/tree/2500.unit-test-clock-fast.2

the RealTest.test_alice_bob still fails... but why!?

comment:5 Changed at 2015-09-25T10:28:38Z by dawuud

progress here in my dev branch: https://github.com/david415/tahoe-lafs/tree/2500.unit-test-clock-fast.3

i got the mock test_alice_bob test passing... however the real test still fails; it's locked... seems like a dead lock.

comment:7 in reply to: ↑ 6 Changed at 2015-10-05T09:09:27Z by daira

Replying to daira:

Reviewing https://github.com/tahoe-lafs/tahoe-lafs/pull/191.

Thanks meejah, but I think there should be a less disruptive way of solving this. The approach in this commit makes me nervous because it's effectively testing different code than actually runs in production. It should be possible to just set the 'processed' hook earlier if the problem is as described in the comment at line 375 of test_magic_folder.py.

So, -1 on the review.

comment:8 Changed at 2015-10-05T09:22:50Z by daira

Yeah, it looks like the problem is that Bobs 'processed' hook needs to be set before Alice writes the file.

Version 0, edited at 2015-10-05T09:22:50Z by daira (next)

comment:9 Changed at 2015-10-08T02:52:45Z by meejah

See: https://github.com/tahoe-lafs/tahoe-lafs/pull/195 which uses the Clock() approach.

comment:10 Changed at 2015-10-26T08:36:15Z by dawuud

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.