Home/ Questions/Q 767755
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T18:04:30+00:00

For the sake of this question, I don’t care about the difference between stubs,

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0