Mocking IScheduler for unit testing

Question

I'm trying to test rx.net code and I'm totally confused how to go about it. An example from this website was quite helpful, but I'm unable to connect the final piece. Below is a sample code:

class SomeClass 
{

  constructor(IScheduler scheduler)
  {
    var interval = Observable.Interval(TimeSpan.FromSeconds(1), scheduler)
      .Take(5);
  }

}

// So in my unit test project I'll inject a TestScheduler as below

public void Test_Some_Class()
{
   var scheduler = new TestScheduler();
   var instance = new SomeClass(scheduler);
   ...
}

My question is in my startup file, which implementation of IScheduler should I use:

services.AddSingleton<IScheduler, ConcreteImpl>()

This stackoverflow question was quite helpful, but I'm still unable to piece everything together :(

Why would you register any startup thingy within the scope of a unit test? — grek40, Aug 27 '19 at 15:38
Sorry but the unit test is in its own project. I've updated the question to reflect that. — David Blay, Aug 27 '19 at 15:49

score 1 · Answer 1 · answered Aug 27 '19 at 15:16

1

You would use AsyncConversions. Something like this,

services.AddSingleton<IScheduler, SchedulerDefaults.AsyncConversions>()

answered Aug 27 '19 at 15:16

Ishraq Ahmad

1,049
1
12
22

David Blay · Answer 2 · 2019-08-28T08:53:28.540

For some interesting reason, I was got a run-time error yesterday, but everything is working now. Hmm! You can use: services.AddSingleton<IScheduler>(DefaultScheduler.Instance); for TimeBasedOperations or follow the example here

    public interface ISchedulerDefaults
    {
        IScheduler AsyncConversions { get; }
        IScheduler ConstantTimeOperations { get; }
        IScheduler Iteration { get; }
        IScheduler TailRecursion { get; }
        IScheduler TimeBasedOperations { get; }
    }

and reference that instead services.AddSingleton<ISchedulerDefaults, SchedulerDefaults>();

For your unit tests you can use:

    public sealed class TestSchedulerDefaults : ISchedulerDefaults
    {
        private readonly TestScheduler _timeBasedOperations = new TestScheduler();
        private readonly TestScheduler _asyncConversions = new TestScheduler();
        private readonly  TestScheduler _constantTimeOperations = new TestScheduler();
        private  readonly TestScheduler _iteration = new TestScheduler();
        private  readonly TestScheduler _tailRecursion = new TestScheduler();

        IScheduler ISchedulerDefaults.AsyncConversions => new TestScheduler();
        IScheduler ISchedulerDefaults.ConstantTimeOperations => new TestScheduler();
        IScheduler ISchedulerDefaults.Iteration => new TestScheduler();
        IScheduler ISchedulerDefaults.TailRecursion => new TestScheduler();
        IScheduler ISchedulerDefaults.TimeBasedOperations => _timeBasedOperations;


        public IScheduler AsyncConversions => _asyncConversions;
        public IScheduler ConstantTimeOperations => _constantTimeOperations;
        public IScheduler Iteration => _iteration;
        public IScheduler TailRecursion => _tailRecursion;
        public TestScheduler TimeBasedOperations => _timeBasedOperations;
    }

Isn't it overkill with that many schedulers? [ReactiveUI](https://reactiveui.net/docs/handbook/scheduling/) only has two, because often all you care about is if your tasks run in the background or on the main thread. — Magnus, Sep 06 '19 at 17:03
Sure @Magnus, you definitely don't need all. I just provided the full implementation. — David Blay, Sep 10 '19 at 06:07

Mocking IScheduler for unit testing

2 Answers2