Version control - stubs and mocks

Question

For the sake of this question, I don't care about the difference between stubs, mocks, dummies, fakes, etc.

Let's say I'm working on a project with one other person. I'm working on component A and he is working on component B. They work together, so I stub out B for testing, and he stubs out A. We're working in a DVCS, let's say Git, because that's actually the case here.

When it comes time to merge our components together, we need to get the "real" files from my A and his B, but throw away all the fake stuff. During development, it's likely (unless I need to learn how to properly stub things) that the fakes have the same file names and class names as the real thing.

So my question is: what is the proper procedure for doing version control on the fakes, and how are the components correctly merged, making sure to grab the real thing and not the fake? I would guess that one way is just do the merge, expect it to say CONFLICT, and then manually delete all the fake code out of the half-merged files. But this sounds tedious and inefficient.

Should the fake things not go under VC at all? Should they be ripped out just before merging? Sorry if the answer to this should be obvious or trivial, I'm just looking for a "suggested practice" here.

edit: some more information that I didn't realize would prove important. I'm specifically talking about web development, more specifically, I'm NOT talking about .NET development. My history seems to have misled people in that regard.

Answer 1

The fakes should still be in source control, probably under a different package/namespace, in order to be used by unit tests. Have integration tests which use both real components, but keep the unit tests isolated.

Your production code should refer to interfaces or abstract base classes, and have the implementations injected so that you can use the fakes for test but the production classes for the real thing.

Answer 2

There's a .gitignore file for git that allows you to not include files in your source control.

Also you should use a dynamic mock if possible. For .NET something like Rhino.Mock or Moq allows you to programmatically make mocks instead of keeping files & fakes around.

Answer 3

So basically this is the situation (to make sure I'm understanding correctly):

• Unit tests for component A are written against fake component Bs
• Component B wasn't ready, but now it is
• You want to refactor the tests to use the real component B instead of the fakes

I would actually not recommending doing that last step. I would leave the existing unit tests for A written against fake Bs, because they are supposed be testing A. Now that A and B are both ready, I would write a new set of integration tests that test the interaction between A and B.

As for the fakes and real classes having the same names, I would fix that with some policy that you and the other developer agree upon on where to keep fakes in the file structure as opposed to real classes.