.debounce doesn't seem to work as expected

[jacobbullock]

Describe the bug
I have been following along with Episodes 100-103 and coding along. I understand that quite a bit has been improved since those episodes were made, but the code is all compiling until episode #103 around 8:40 where debounce is introduced.

To Reproduce
TCA.zip

Code here is in ContentView.swfit around line 67

When I run the tests with

        case .todo(index: _, action: .checkboxTapped):
            struct CancelDelayId: Hashable { }
            return Effect(value: AppAction.todoDelayCompleted)
                     .delay(for: 1, scheduler: DispatchQueue.main)
                     .eraseToEffect()
                     .cancellable(id: CancelDelayId(), cancelInFlight: true) // cancelInFlight

They all run as expected. However, changing that to a debounce as described in the video to:

        case .todo(index: _, action: .checkboxTapped):
            struct CancelDelayId: Hashable { }
            return Effect(value: AppAction.todoDelayCompleted)
                    .debounce(id: CancelDelayId(), for: 1, scheduler: DispatchQueue.main)

there are errors in the test, all to do with not receiving the expected events. I am fine to move on with the other code and will look to see how things change when the scheduler is introduced, but this seems like a bug with debounce possibly using DispatchQueue.main? Running the app in the simulator and tapping on the check box does in fact sort after 1 second.

Expected behavior
I am expecting that debounce method to function the same as the long form version with the delay and effect eraser.

Environment

• swift-composable-architecture version 0.30.0
• Xcode 13.0

[mbrandonw]

Hi @jacobbullock, I believe this is just due to the imprecision of using test expectations for waiting exact amounts of time. The reducer is debouncing for 1 second and we are telling the test suite to wait 1 second so that the effect can get past the debounce. It seems that at the time of recording that episode that worked fine, but now the test suite needs a little more time to wait.

If you change the expectation to wait just a bit longer, like say 1.01 seconds:

XCTWaiter.wait(for:[self.expectation(description: "wait")], timeout: 1.01)

Then the test suite will pass.

This all goes to show how imprecise using live schedulers in TCA tests can be, which is why we highly recommend using a test scheduler and that is done in the second half of episode 103.

[iampatbrown]

Hey @jacobbullock,
I was able to tests your code successfully using DispatchQueue.test.

Did you update your reducer to use environment.mainQueue instead of DispatchQueue.main?

 return Effect(value: AppAction.todoDelayCompleted)
  .debounce(id: CancelDelayId(), for: 1, scheduler: environment.mainQueue)

[jacobbullock]

@iampatbrown yes, that was the problem 🤦‍♂️ . Thanks for helping my tired eyes. I was trying to play around with this to see if there was some change to the debounce method that caused the need for the extra delay on XCTWaiter and forgot to update when I did the refactor.

[iampatbrown]

Awesome :) Glad you got it sorted.

[mbrandonw]

Thanks for helping out @iampatbrown, and glad you got it sorted @jacobbullock!

Completely unrelated, @mbrandonw, but are you the Brandon Williams that contributed to the Flash Math Creativity book back in the day?

😳 lol that is me. My Flash past pops up to haunt me every once in awhile!

[jacobbullock]

I loved those types of books. I spent a significant amount of time with the math creativity books in college when I was trying to convince my profs that art from code was not a threat to traditional art mediums =). Your chapter, if I remember correctly, was on faking 3d and I used that to do some fun stuff with image manipulation. Thanks again.