In few words, what can be said about Mocking process in TDD

Question

I'd like to brush my brain to avoid confusions. In few words, what can be said about Mocking process in TDD

1. What's the GREAT idea behind MOCKING?
2. Mocking frameworks are meant to be used only to avoid accessing DB during tests or they can be used for something else?
3. For new comers (like me), are all the frameworks equal or I need to choose one for this or that reason?

Answer 1

1. The GREAT idea: LIMIT THE SCOPE OF YOUR TESTS. By removing dependencies you remove the risk of test failures because of dependencies. That way you can focus on the correctness of the code that USES those dependencies.
2. Mocking DB's is very common but you can mock any dependency with an interface. In a recent project we mocked a web service, for example. You might even want to mock another business object just to make sure that you aren't relying on the correctness of the logic in that object.
3. I'd choose whichever one seems easiest to use. Moq is really nice.

Answer 2

I suggest you start here:

Mocks are not Stubs

It probably is the article that got me thinking the right way about Mocks. Sure the mocked object is usually heavy (otherwise it may not be worth mocking) but it doesn't have to be heavy in the sense that has some strong reliance on an external system like a database. It can be just a complex piece that you need to isolate to effectively be testing only your class and not the dependency.

Answer 3

In addition to eliminating databases and other slow or ancillary concerns from the unit being tested, mocking allows you to start writing tests for a class without having to implement any collaborating classes.

As you design some piece of functionality, you'll realize that you need some other class or service, in order to stick to the single responsibility principle, but then you'll have to implement those to get the first one working, which in turn will demonstrate the need for still more classes.

If you can mock or stub those dependencies, then you can create the interfaces upon which that first class will rely, without actually having to implement anything outside of that class -- just return canned results from stubs of the interfaces.

This is an essential component to a test-first approach.