Alternatives to using custom pipelines for improved unit testability

Question

What are common or effective approaches for making Pipelines in Sitecore unit testable? I recently updated some code to use custom pipelines and then found I could no longer unit test it :-(

In the past, I have set up unit test projects which load up all the config files and actually connect to Sitecore, but I don't think this is really best-practice, so want to avoid this if possible.

I am currently using FakeDb along with xunit and a load of other test-related libraries such a Moq, NSubstitute etc. I'm aware I could unit test individual pipeline steps, but could not test the method in question without invoking the whole pipeline.

Answer 1

Had a bit of a think about how to do this:

Test the processor steps

So the first thing to do is make sure all your code logic is off loaded to a service or manager class. The processor class really should just be responsible for creating the service/manager class (by constructor injection of course :) ) and then calling the appropriate method.

So the main set of unit testing can be done for the individual functionality of the pipeline.

Test the processor

With the container now being a part of Sitecore in 8.2+, you can now test some processors directly. Pipelines now support the resolve="true" attribute that will use the container to create the processor and inject any dependencies. So those are now testable. For processors that do not inject dependencies, you are back to FakeDb and mocking everything.

Test the pipeline

To test the pipeline as a whole and not have all the Sitecore binaries, config etc... (I agree, this isn't a great practice), we are going to have to write our own version of CorePipeline.Run as a kind of test harness. That would then take the args and push them through the Process Method of each processor.

Initially - this sounds like it would be fairly simple to do, at a very basic level you could even do something as simple as:

public void TestMyPipeline()
{
    var args = new Mock<ProcessorArgs>();

    // TODO: populate the properites on the args mock

    var processor1 = new Processor1(dependency1Mock.Object, dependency2Mock.Object);
    processor1.Process(this, args);

    var processor2 = new Processor1(dependency1Mock.Object, dependency2Mock.Object);
    processor2.Process(this, args);

    // etc...

    // Add your test assersions
}

But... ultimately, you still have the same problem. You need to mock or create any dependencies that get used in those processors and there is a lot to setup.

What is the best option?

For me - generally, unit testing each processor individually normally covers 99% of what is going to require testing. The extra overhead of running the entire pipeline gets into the rule of diminishing returns.

But you would have to evaluate how far you wanted to take the testing for your project.