Question

In brief: What is the pattern called in the following code, and how should it be tested?

The purpose of the code is to encapsulates a number of actions on a zip file (written in C#, although the pattern is language independent):

public class ZipProcessor
{
    public ZipProcessor(string zipFilePath) { ... }

    public void Process()
    {
        this.ExtractZip();
        this.StepOne();
        this.StepTwo();
        this.StepThree();
        this.CompressZip();
    }

    private void ExtractZip() { ... }
    private void CompressZip() { ... }
    private void StepOne() { ... }
    private void StepTwo() { ... }
    private void StepThree() { ... }
}

The actual class has around 6 steps, and each step is a short method, 5-15 lines long. The order of the steps is not important, but Extract and Compress must always come first and last respectively. Also, StepTwo takes much longer to run than the rest of the steps.

The following are options I can think of for testing the class:

• Only call the public Process method, and only check the result of one step in each test method (pro: clean, con: slow, because each test method calls StepTwo, which is slow, even though it doesn’t care about the result of StepTwo)
• Test the private steps directly using an accessor or wrapper (pro: simple, clear relation to what is run during a test and what is actually tested, con: still slow: extracts and compresses multiple times, hacky: need to use a private accessor or dynamic wrapper, or make the steps internal in order to access them)
• Have only one test method that calls a bunch of smaller helper test methods (pro: fast, models the class more closely, con: violates “one assert per test method”, would still need to run multiple times for different scenarios, ex. StepOne has different behavior based on input)

Answer 1

There’s not really a pattern reflected here, but you could rewrite your code to use the Strategy or Chain of Responsibility patterns, as pointed out Paul Michalik. As is, you basically just have a custom workflow defined for your application’s needs. Using the Chain of Responsibility pattern, each step would be its own class which you could test independently. You may want to then write an integration test which ensures the whole process works end-to-end (component or acceptance level test).