Re: Re: Where to put test code

I think we all misunderstood our messages. (There's that darn communication 
problem again!)

As usual, more information clears things up.

Agile is about having the ability to reactly quickly (almost instantly) to 
change. The question is whether the decisions you make now will be impacted 
by changes down the road. If your team can handle future changes 
(unpredictable by definition) in an agile manner (quickly, efficiently, etc) 
then your method works.

I personally believe (in the case of libraries) that tests should verify 
specifications (ie, promises made by interfaces). The authors of C++ FAQs 
contrast proper and improper inheritance. Proper inheritance is a really 
cool concept; actually, it's almost too obvious but I see people making the 
mistake often. Oh, when I talk about interfaces I mean in a general sense 
rather than in a .NET specific sense.

I suppose the internal problem here is very much so .NET specific. The 
closest thing Java has is the so-called "default" access modifier (no 
modifier at all) which allows package access which more like namespace 
access in .NET. The closest thing C++ has is friend and that's specified at 
an artifact by artifact basis.

I believe, personal opinion, that many "neat" features of .NET (like 
internal) are residual from COM, usually make things more complex, and cause 
developers to think way too much. They are well intended and have purpose 
(otherwise, they wouldn't exist), but for the most part they should be used 
sparingly.

That said, I think using internal for encapsulation purposes can be very 
useful. As I said in a different email, I like to keep my tests close to the 
classes they test. Something like the following in .NET:

namespace A
{
#if Test
    namespace Test
    {
        /* Test class */
    }
#endif

    /* Class */
}

That allows me to keep my tests close to the thing I'm testing (as a 
cohesive unit), no questions about accessibility, and allows me to remove 
the tests by not defining the #define Test.

In the end I think we were disagreeing on the interpretation of philosophy 
rather than anything else. From your descriptions you definitely follow TDD 
as closely as your implementation environment allows you to. Because of that 
I appologize for my previous rudeness. No one deserves that.

(World's largest software company, eh? Must be a hardcore Linux programmer 
switching over to Mono! Just a joke! 

----- Original Message ----- 
From: "Brian Button" <bbutton <at> agilestl.com>
To: <testdrivendevelopment <at> yahoogroups.com>
Sent: Friday, October 01, 2004 6:28 AM
Subject: Re: [TDD] Re: Where to put test code

> 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.
>
> Edwin,
>
> 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
> them internal.
>
> I'd appreciate your opinion on how we're missing the TDD boat. I can
> always get better...
>
> bab
>
> -- 
> Brian Button bbutton <at> agilestl.com
> 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]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
> 

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/