Reactive: TestScheduler bug delay subscription time by 1 tick when 0 is given

[hussein-aitlahcen]

There is a problem with the TestScheduler from the testing framework.
When i call the Start method with 0 as the _subscribed_ param, it call the ScheduleAbsolute method and the dueTime = Clock + 1 trigger.
Because of that, in my test case, every messages are delayed by one tick.

I think that the dueTime = Clock + 1 was implemented because of this.
So, I guess that changing the comparison with >= and removing the dueTime = Clock + 1 would fix that.

The problem doest not occur with a subscribed time > 0.

using System;
using System.Reactive.Linq;
using System.Reactive.Concurrency;
using Microsoft.Reactive.Testing;
using Xunit;

namespace Cycle.Net.Sample.Test
{
    public class Test : ReactiveTest
    {
        [Fact]
        public void TestX()
        {
            var scheduler = new TestScheduler();

            var source = scheduler.CreateColdObservable(
                OnNext(100, 1),
                OnNext(200, 2),
                OnNext(300, 3),
                OnCompleted<int>(500)
            );

            /*
                This will work with subscribed > 0 
                but trigger exception with 0 as shown with this test,
                because our subscription get delayed.

[xUnit.net 00:00:00.7707121]       Expected: [OnNext(1)@100, OnNext(2)@200, OnNext(3)@300]
[xUnit.net 00:00:00.7707640]       Actual..: [OnNext(1)@101, OnNext(2)@201, OnNext(3)@301]
             */
            var subscribed = 0;
            var observer = scheduler.Start(() => source, 0, subscribed, 500);

            ReactiveAssert.AreElementsEqual(new[]
            {
                OnNext(100 + subscribed, 1),
                OnNext(200 + subscribed, 2),
                OnNext(300 + subscribed, 3)
            }, observer.Messages);
        }
    }
}

[reduckted]

I'm glad someone else is experiencing this bug, because I thought I was going crazy 😵

I haven't looked into it too much, but I'm not sure why ScheduleAbsolute needs to add one tick to the time in the first place. I'm sure it was put there for a reason, so I may be missing something. 😄

[akarnokd]

Yes, probably a mistake started by that wrong comparison. The change looks reasonable but it will fail 164 unit tests that relied upon that 1 tick drift in some form and others prevent the test run from completing entirely.