Mocking Frameworks about tech-radar HOT 10 CLOSED

I like that NSubstitute doesn't require setup lambdas and .Object calls like Moq.

from tech-radar.

NSubstitute was fine for me

from tech-radar.

Sounds sensible @samblackburn - wonder if we could be a bit more opinionated though? If we have too much in "Explore" then we'll not start to converge.

Adopt - NSubstitute (easier to use than Moq as @ChrisHurley mentioned)
Endure - Moq (as @samblackburn says changing it over for the sake of uniformity seems like a bad idea so endure seems more sensibel than retire)
Explore - Fakes (as a technique)
Retire - Rhino Mocks (doesn't support .NET Standard / .NET Core and not actively maintained).

from tech-radar.

I suppose another consideration is that if you find yourself creating lots of elaborate mocks, maybe it's time to use fakes instead. They're used quite a lot in the Redgate Usage Client. Here's one if its internal interfaces for accessing the registry:

https://github.com/red-gate/RedGate.Usage.Client/blob/master/RedGate.Usage.Client/Providers/Registry/IRegistryProvider.cs

And here's a corresponding fake used in the tests:

https://github.com/red-gate/RedGate.Usage.Client/blob/master/RedGate.Usage.Client.Tests/Providers/Registry/FakeRegistryProvider.cs

Given the amount of mocking of IRegistryProvider that we previously had in our tests, replacing them with a fake got rid of loads of code and made the associated tests much simpler.

from tech-radar.

Not sure where "Fakes" fit in the mocking frameworks part of the tech radar, though. They're really more of a technique for avoiding mocking frameworks.

from tech-radar.

personal opinion: the first question to answer is "Do I need a mocking library?" The answer here will depend on what kind of TDD you're doing and how you're arranging your boundaries.

I don't know how this question fits on the Tech Radar :)

If you've decided you want a mocking library, I think they're all roughly equivalent and fine to use - I've had a decent experience with Moq and a terrible experience with RhinoMocks (although to be fair in the latter case we were using the old record/playback API with strict mocks, which turned out to be a terrible idea which I believe RhinoMocks has since moved away from). Just pick the one which you think has the best syntax?

from tech-radar.

I have an irrational prejudice against Moq because it has a stupid name. Other than that I've never found a substantial difference between NSubstitute and Moq so we should pick whatever one we are using in most products to put in the middle and stick the other one out in Endure.

from tech-radar.

FWIW, COREDev had an interesting reason for using RhinoMocks rather than NSubstitute or Moq. With the latter two libraries, you can often end up writing code that follows this pattern:

1. Set up your mock objects in some non-trivial way.
2. Exercise your SUT.
3. Verify the expectations in your mock objects in a way that precisely duplicates the code in step 1.

The more elaborate the mock set up becomes, the more horrible that duplication becomes. That said, I've found it hard to find a good example. Here's a simpler example, though (see how _databaseSchemaSynchronizer is used). The duplication is avoided with RhinoMocks because the test pattern looks like this instead:

1. Set up your mock objects in some non-trivial way.
2. Exercise your SUT.
3. Verify all expectations with a single call to .VerifyAllExpectations() on your mocks objects.

When the bulk of the tests involve setting up the mocks, as often turns out to be the case, it results in much more compact, readable tests.

from tech-radar.

Rhino Mocks - last commit Oct 11 2010 (https://github.com/hibernating-rhinos/rhino-mocks). Groups suggests it'll never support .NET Core.

Retire:

• Rhino Mocks.

Both Moq / NSubstitute are actively developed

from tech-radar.

Multiple mocking frameworks can coexist so at least the change can be made incrementally. That said, I don't think I'd bother moving a large test suite from Moq to NSubstitute or vice versa just for the sake of uniformity.

Mocks vs fakes are different tools for different jobs: A simple Mock<IFur>() will let me avoid nullrefs without the risk of side effects, while a fake makes more sense when the same complex behaviour is needed by many tests.

I think this puts fakes, Moq and NSubstitute into "Explore" but I could be persuaded otherwise.

from tech-radar.