Is there an interface wrapper around a parallel task library so that I can change it to unit testing?

I asked this question a while ago. Now I know that this is a bad idea, and that the encapsulation of the planning and execution of tasks must be abstracted so that the synchronous scheduler can be passed from unit tests.

I currently have code that uses the Task Parallel Library (TPL), and I would like to add something like ITaskScheduler to my types to take responsibility for planning and let me go through the synchronous alternative in my tests.

Is there such a thing? I am looking for something that wraps Task.Factory.StartNew and Task.ContinueWith . I do not think that it does not work too much to roll on its own, but I am sure that there are many small mistakes, and I do not want to waste time on it if it is already available.

+3
source share
2 answers

Substitution of the Task class is difficult even if you inherit a new class from Task : since TaskScheduler and TaskFactory are not common for Task , this will not help at all.

In my experience, it's better to use the native TaskScheduler class (inherited from TaskScheduler ). You can pass it to the TaskFactory constructor, and then use its TaskFactory .

Now for testing, you can use another TaskScheduler with varying degrees of parallelism (up to 1 thread, if you want), and you can add an additional log to your TaskScheduler class to register each task as it starts and finishes.

+5
source

You can define such an interface and wrap the actual library classes inside the facade that implements the interface. For testing, replace your Façade with an object layout.

+2
source

All Articles