Difference between shims and stubs

Question

Can anyone tell me very clearly what\'s the main difference between a shim and a stub during unit testing?

I know about mock objects and I

Answer 1

From what I understood, the difference is where the mocked code resides or which part of code you mocked (i.e. the "where" gives the distinction). So I would put it as:

You call Stub the part of your code which you mocked while it will be called Shim if you mock some external call.

• "your code" being the code to be tested
• "external call" is the dependency on which your code depends

I found this reference good: My two cents on fakes, stubs, mocks, and shims esp the part "A general rule is to take advantage of stubs for internal calls and shims for external assemblies."

Answer 2

Shims are generally used to provide mocks from assemblies outside of your solution, whereas stubs are used to create mocks of classes within your solution.

Example of Stubs

// Create the fake calculator:
ICalculator calculator = new Calculator.Fakes.StubICalculator()
{
// Define each method:
Add = (a,b) => { return 25; }
};

Example of Shims

//Using shims to control the response to DateTime.Now
using (ShimsContext.Create())
{
// insert the delegate that returns call for DateTime.Now
System.Fakes.ShimDateTime.NowGet = () => new DateTime(2010, 1, 1);
MethodThatUsesDateTimeNow();
}

Courtesy: Exam Ref 70-486

Answer 3

Let me cite Martin Fowler's article Mocks Aren't Stubs:

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

So mocks can directly make a test fail if an expectation is violated. Stubs don't do that.

Shims (or Moles) differ from both of them in that they can be used to replace hard-coded dependencies like static methods. You should avoid that IMO and prefer a refactoring, which makes these dependencies replaceable. See this thread for further discussion, especially Jim Cooper's answer.

Answer 4

As a general guide, use stubs for calls within your Visual Studio solution, and shims for calls to other referenced assemblies. This is because within your own solution it is good practice to decouple the components by defining interfaces in the way that stubbing requires. But external assemblies such as System.dll typically are not provided with separate interface definitions, so you must use shims instead.

It's very good reference.