Instead of patching with a class that gets its attributes overwritten, please patch with an instance that gets thrown away, so there's no need to reset the class attributes like in the code above.
For instance:
"self.patch(gui, 'LoopingCall', FakeLoopingCall)" ->
"self.patch(gui, 'LoopingCall', FakeLoopingCallClass())"
This is present a few times in this branch, so make sure all occurrences end up fixed.
---
Also, to test code that uses LoopingCalls (and reactor.callLaters, too) remember that you can use twisted.internet.task.Clock, by patching the LoopingCall.clock attribute. Then you will be able to fake the reactor moving forward in time by calling clock.advance.
This gives you a lot of flexibility to test this kind of code, and the tests end up a lot faster and reliable than if they were using a small value for the LoopingCall or callLater time.
This style of coding tests is very ugly and error prone:
534 + def _clean_ fake_window_ class(self) : called = [] close_callback = None fake_icon_ class(self) : auto_update = None fake_looping_ call_class( self): .function = None .args = None .kwargs = None .called = []
535 + """Clean the fake window class."""
536 + FakeMainWindow.
537 + FakeMainWindow.
538 +
539 + def _clean_
540 + """Clean the fake icon class."""
541 + FakeTrayIcon.window = None
542 + FakeTrayIcon.
543 +
544 + def _clean_
545 + """Clean the fake looping call class."""
546 + FakeLoopingCall
547 + FakeLoopingCall
548 + FakeLoopingCall
549 + FakeLoopingCall
Instead of patching with a class that gets its attributes overwritten, please patch with an instance that gets thrown away, so there's no need to reset the class attributes like in the code above.
For instance: Class() )"
"self.patch(gui, 'LoopingCall', FakeLoopingCall)" ->
"self.patch(gui, 'LoopingCall', FakeLoopingCall
This is present a few times in this branch, so make sure all occurrences end up fixed.
---
Also, to test code that uses LoopingCalls (and reactor.callLaters, too) remember that you can use twisted. internet. task.Clock, by patching the LoopingCall.clock attribute. Then you will be able to fake the reactor moving forward in time by calling clock.advance.
This gives you a lot of flexibility to test this kind of code, and the tests end up a lot faster and reliable than if they were using a small value for the LoopingCall or callLater time.