Edwin Gabriel Castro wrote:
> All good points.
> How did you determine you needed a facade? How did you determine the
> interfaces to the "work-horse" classes? It sounds to me like you have
> already designed the system. At this point I don't feel like you are doing
> TDD anymore. You are testing. Put your tests where they make sense.
I'm still pretty sure I'm writing my code test first. I don't have a
design on paper for what I'm writing, I'm writing tests before I write
code, and I'm eliminating duplication after each test. If I'm missing
something, please let me know.
What I am doing, however, is conforming to the requirements that I have.
We're building a library, so the interface is pretty important. The
domain experts have told us how clients will use our library, based on
client feedback and their own experiences, but we are completely free to
implement anything we want under the covers. We just have to do our best
to make the given interface work.
Does that mean that I can't do TDD? Certainly not. It just means that my
interface to the world is fixed. On larger teams this happens all the
time, and in one sense, I'm writing software for a team that numbers in
the tens of thousands (think world's largest software company).
> If I was TDD a system I would begin TDD the classes as public since my tests
> need access to them and my tests reflect "user" usage. At a later point I
> decide the system has become to difficult to use and decide to use a facade
> to simplify it I would begin at that point by adding another public
> interface (the facade), writing the tests first reflecting the new "user"
> usage. If prior to release you need to restrict the end user from accessing
> the "work-horse" classes then you make them internal (in a .NET environment)
> and at that point decide how to update your tests so that you can still use
> them during maintanance. In TDD (and in agile methods in general) you want
> to make decsions as late as possible. If you are running into problems about
> where tests should be at an early stage of the game then you are making too
> many descisions.
I understand and appreciate how you would do this. I, in fact, have
developed code like this many times. But part of gaining mastery over
any of the agile practices is that you're allowed to start modifying it
to suit your own purposes better. I'm working on a team with two other
TDD masters, and we're led by the guy who wrote NUnit. Given our
circumstances, and the overriding need to keep our API as simple and
unpolluted by implementation details as possible, it is essential for us
to keep certain classes internal. And it is obvious to us which classes
those are. During our own development, we have certainly had cases where
classes that we originally thought were going to be strictly internal
turned out to need to be public, and we changed them. No big deal.
But we are still hiding most of our implementation classes by making
I'd appreciate your opinion on how we're missing the TDD boat. I can
always get better...
Brian Button bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO 636.399.3146
Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl
[Non-text portions of this message have been removed]