TDD - Creating a new class in an empty project to make dependencies explicit as they are added

Using TDD, I'm considering creating an (throw-away) empty project as Test-harness/container for each new class I create. So that it exists in a litt开发者_运维百科le private bubble.

When I have a dependency and need to get something else from the wider project then I have to do some work to add it into my clean project file and I'm forced into thinking about this dependency. Assuming my class has a single responsibility then I ought not to have to do this very much.

Another benefit is an almost instant compile / test / edit cycle.

Once I'm happy with the class, I can then add it to the main project/solution.

Has anyone done anything similar before or is this crazy?

I have not done this in general, create an empty project to test a new class, although it could happen if I don't want to modify the current projects in my editor.

The advantages could be :

• sure not to modify the main project, or commit by accident
• dependencies are none, with certaintly

The drawbacks could be :

• cost some time ...
• as soon as you want to add one dependency on your main project, you instantly get all the classes in that project ... not what you want
• thinking about dependencies is usual, we normally don't need an empty project to do so
• some tools check your project dependencies to verify they follow a set of rules, it could be better to use of those (as that could be used not only when starting a class, but also later on).
• the private bubble concept can also by found as import statements.
• current development environments on current machines already give you extra-fast operations ... if not, you could do something about it (tell us more ...)
• when ok, you would need to copy to your regular project your main and your test class. This can cost you time, especially as the package might not be adequate (simplest possible in your early case because your project is empty, but adequate to your regular project later).

Overall, I'm afraid this would not be a timesaver... :-(

I have been to a presentation for using Endeavour. One of the concepts they depended highly upon was decoupling as you suggest:

• service in seperate solution with its own testing harness

Endeavour is in a nutshell a powerfull development environment / plugin for VS which helps archieving these things. Among a lot of other stuff it also hooks into / creates a nightly build from SourceSafe to define which dll's are building and places those in a shared folder.

When you create code which depends on an other service you don't reference the VS project but the compiled DLL in the shared folder.

By doing this a few of the drawbacks suggested by KLE are resolved:

• Projects depending on your code reference the DLL instead of your project (build time win)
• When your project fails to build it will not break integration; they depend upon a DLL which is still available from last working build
• All classes visible - nope

Middle ground:

• You REALLY have to think about dependency's, more then in 'simple' setups.
• Still costs time

But ofcourse there is also a downside:

• its not easy to detect circular dependency's

I am currently in the process of thinking how to archieve the benefits of this setup without the full-blown install of Endeavour because its a pretty massive product which does really much (which you won't all need).