Using shims to turn my integration tests into unit tests

I want to understand how to properly unit test a function such as this. The function doesn't return anything, but it does call other functions that themselves have already been unit tested. My understanding is that in order to properly unit test this method I will have to shim the dependant methods - otherwise this is just an integration test.

public void ResetColours(Colours colour)
{
    var colourInfo = colour.GetInfo();
    for (int i = 0; i < 9; ++i)
        this.SetColourInfo(i, colourInfo);
}

I'm having a hard time deciding on the right way to shim the methods. At the moment I am thinking of doing this - shim the GetInfo method so that it returns a hard coded value, then have the SetColourInfo shim remember the information that was passed in to make sure it matches.

[TestMethod]
public void ResetColours()
{
    Info[] colourInformation = new Info[9];

    using (ShimsContext.Create())
    {
        ShimColourExtensions.GetInfoColours = (Colours colour) => new Info("test");
        ShimFace.AllInstances.SetColourInfoIntInfo =
            (index, colourInfo) => colourInformation[index] = true;

        this.TestObject.ResetColours(Colours.Brown); //TestObject was initialized in my init method
        //ASSERT that hard coded GetInfo value was set into each array index
    }
}

Is this a valid unit test? Could I be doing anything better in situations like this? Should I even be writing a unit test for a method like this?

There was no need to delete the post on Stack Overflow, it belonged there just fine; perhaps even better than here.

You don't have to shim anything. Integration tests are tests that use an external dependency (system time, external API, filesystem, etc). In your case all your "dependencies" are simply method calls in your own project.

Here in your case this can simply be seen as a unit test: you're testing a single public method (~ unit) which encapsulates smaller unit tests. This is a perfectly valid unit.

Integration testing refers to a bigger set of components that and testing how these major interfaces work together.

Now, on to the bigger question: how do you test this [void method]? As is tradition: a link to an answer of mine.

void methods change the state of your program (adjusting values of variables) or they interact with an external dependency (printing to the console, logging to a file). So in order to assert against any expectations you'll have to either interpret the results or intercept them along the way.

Interpreting results

In the first case (adjusting of a variable) the answer is obvious: look at the variables that got changed and see if they now have the values you want.

In the latter case you get a "problem": you're now reading the result of an external dependency so you're entering the realm of integration testing. This is why we have the alternative solution..

Intercepting results

This is done with shims, mocks, stubs, seams, you name it. You're already aware how this works: a DI framework intercepts the call and you can provide your own values around the actual call, or you inject the unit under test with a specific implementation for testing purposes.

StackExchange Code Review Q#51581, answer score: 3