Rationalise TestScheduler.Start() overloads

[LeeCampbell]

I have had a concern that the three overloads of TestScheduler.Start() all seem to do slightly different things.

The Start() method inherited from VirtualTimeScheduler simply drains the scheduled items from the queue until empty or until Stop() is called.

The Start(Func<IObservable<T>>,..) methods however create an Observable sequence from the provided function and will execute the creation, subscription and unsubscription at given times.
It then returns the ITestableObserver<T> that will be subscribed to the created observable sequence.
While I can see this as being useful, I do find it odd that these methods share the same method name as the method from the base class VirtualTimeScheduler.
I also find the use of seemingly random default values for create/subscribe/dispose times coming from ReactiveTest.Create/Subscribed/Disposed to be surprising.
Showing these methods to other developers, they have also tended to agree that "magic numbers" were in direct conflict with the principle of least surprise.
These numbers assume that 100, 200 and 1000 ticks are appropriate values or even in the appropriate order of magnitude for testing in everyone's domain - which is surely nonsense?

My point is that one Start() method drains the scheduler's queue, the other creates things, schedules things, returns things, and calls that Start() method.

My suggestions are

• to drop the magic numbers and the overloads that use them.
• rename either VirtualTimeScheduler.Start() and VirtualTimeScheduler.Stop to VirtualTimeScheduler.Run() and VirtualTimeScheduler.Pause() or rename TestScheduler.Start to TestScheduler.Run(?)

[snboisen]

I agree completely. Whenever I return to writing a test for Rx-based code, I get confused by the various Start overloads, that do wildly different things. And I never use the versions of Start with prefilled values for any of created/subscribed/disposed. I think adding these overloads was a pretty bad idea, since they do nothing but lure lazy developers to write bad code.

[akarnokd]

@bartdesmet any suggestions?

[NickLydon]

Still running into this issue today. Taking the unit tests in this repository as an example, it's not obvious where the 200 ticks added to every assertion come from.

Also as soon as colleagues start dealing with events emitted in the range of seconds, their assertions fail because of the disposal at 1000 ticks. There's no error to see what's going wrong - their observables just don't emit any values.