Re: [TDD] Re: Where to put test code
- View SourceEdwin Gabriel Castro wrote:
> All good points.Edwin,
> 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).
>I understand and appreciate how you would do this. I, in fact, have
> 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.
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]
- View SourceI tend to think of acceptance tests as "system-wide" functional tests
representing user stories (use cases). The end user (or a representative) of
the entire system would then write the acceptance tests capturing all of the
requirements (use cases).
I like to think of unit tests as acceptance tests for units (classes,
modules, what have you). In that sense the tests should reflect how that
unit is to be used (interface) and how the unit should respond
(specification). In this perspective, the end users of the unit are the
other developers of the entire system (in multi-developer environments).
I cringe every time I hear people wanting to test internals (not the .NET
keyword :-) because code should not be written unless there is a test for it
first. If the test truly exists first then the test is written from the
perspective of the "user" (some other developer). The purpose of
encapsulation is to decouple interface and specification from
implementation. When the test is written with the purpose to test the
internals I feel that encapsulation is braking at some point. If the test
represents the interface and specification of the unit, then you are
verifying that the unit behaves according to specification regardless of the
implementation and encapsulation is maintained.
I expect most of the misunderstandings due to my original post are due to
inconsistent use of terminology. Terminology can be a dangerous thing. I
can't remember a single role playing session where the game master and at
least one player did not get into an argument due to different
interpretations of the same term (or perhaps the interpretation was
equivalent but the terms used to describe the interpretation meant different
things to different people).
Sorry, that was a little off-topic, but I thought the two situations were
strikingly similar and could help as an example.
----- Original Message -----
From: "George Dinwiddie" <programminglists@...>
Sent: Friday, October 01, 2004 11:18 AM
Subject: Re: [TDD] Re: Where to put test code
> On Fri, Oct 01, 2004 at 09:06:20AM -0700, Edwin Gabriel Castro wrote:
>> I personally believe (in the case of libraries) that tests should verify
>> specifications (ie, promises made by interfaces).
> Would not that be called an Acceptance Test?
> - George
> Yahoo! Groups Links