headers
Michael Feathers | 1 Oct 2004 01:42
Picon

Re: Re: Where to put test code

Brian Button wrote:

> Edwin Gabriel Castro wrote:
> > If I'm *really* test driving the development of a class then my 
> first step
> > is to write a test for a small piece of the functionality. That
> > functionality has to be public by definition. I never add 
> implementation
> > code unless my test is failing. I only refactor to remove 
> duplication... If
> > I run a coverage tool I will see that any refactorings I made (which 
> could
> > be protected, private, or internal) should be covered with the current
> > tests.
>
> But, at least in the .Net world, there are 2 kinds of public. There are
> the true public classes and methods, and there are those that are
> internal. The internal stuff offers services to other classes in the
> same assembly, and these services are complicated enough to need to be
> tested themselves.
>
> We talked about this internally, and we chose to test internal methods.
> And the only way to test them (without using fancy reflection), is to
> put the tests and code in the same assembly. Since we're shipping a
> library, we can't have extra classes cluttering the real public API.
>
I like putting them together too.  When teams want to separate them, I 
always ask why.  Sometimes there is a good reason,
at other times, it is just because people feel uncomfortable having 
their testing code so close to their production code.  If that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edwin Gabriel Castro | 1 Oct 2004 08:30

Re: Re: Where to put test code

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.

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.

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

> Edwin Gabriel Castro wrote:
>> Again, if you begin by writing your tests, ie, your call public methods,
>> then the internal methods are simply refactorings just like private and
>> protected ones.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Edwin Gabriel Castro | 1 Oct 2004 08:46

Re: Re: Where to put test code


Please note, that I don't think keeping test code together with production 
code is a bad thing. I prefer to put my test code in the same file as the 
production code, perhaps within #if TEST #endif to remove the test code from 
releases. I like to keep things as simple as possible.

I feel the most important thing we can learn from TDD is to keep it simple!

----- Original Message ----- 
From: "Michael Feathers" <mfeathers <at> mindspring.com>
To: <testdrivendevelopment <at> yahoogroups.com>
Sent: Thursday, September 30, 2004 4:42 PM
Subject: Re: [TDD] Re: Where to put test code

> Brian Button wrote:
>
>> Edwin Gabriel Castro wrote:
>> > If I'm *really* test driving the development of a class then my
>> first step
>> > is to write a test for a small piece of the functionality. That
>> > functionality has to be public by definition. I never add
>> implementation
>> > code unless my test is failing. I only refactor to remove
>> duplication... If
>> > I run a coverage tool I will see that any refactorings I made (which
>> could
>> > be protected, private, or internal) should be covered with the current
>> > tests.
>>
>> But, at least in the .Net world, there are 2 kinds of public. There are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edwin Gabriel Castro | 1 Oct 2004 08:38

Re: Re: Where to put test code

I like usage coverage too!

----- Original Message ----- 
From: "Kari Hoijarvi" <hoijarvi <at> me.wustl.edu>
To: <testdrivendevelopment <at> yahoogroups.com>
Sent: Thursday, September 30, 2004 9:05 AM
Subject: RE: [TDD] Re: Where to put test code

> >-----Original Message-----
>>From: William Tanksley, Jr [mailto:wtanksleyjr <at> gmail.com]
> 
>>You might call the coverage you get through proper TDD "usage
>>coverage". 
> 
> This is the first time I hear "usage coverage". I like it. 
> 
> Kari
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>

------------------------ Yahoo! Groups Sponsor --------------------~-->
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edwin Gabriel Castro | 1 Oct 2004 08:37

Re: Re: Where to put test code

True path coverage is impossible due to the infinite (or near infinite) 
number of possible paths. In "Test Driven Development By Example" Kent Beck 
discusses an example where he writes six tests for a problem compared to 65 
tests in "Testing Object Oriented Systems". The extra 59 tests may give you 
a lot of confidence on your implementation but they may be adding very 
little real value.

----- Original Message ----- 
From: "Kari Hoijarvi" <hoijarvi <at> me.wustl.edu>
To: <testdrivendevelopment <at> yahoogroups.com>
Sent: Thursday, September 30, 2004 7:25 AM
Subject: RE: [TDD] Re: Where to put test code

>
>>-----Original Message-----
>>From: Edwin Gabriel Castro [mailto:rajaat <at> phreaker.net]
>>Sent: Thursday, September 30, 2004 2:22 AM
>>To: testdrivendevelopment <at> yahoogroups.com
>>Subject: Re: [TDD] Re: Where to put test code
>>
>>There's no way around it. If you write tests first and only refactor for
>>duplication you *will* by definition have 100% coverage! No code is ever
>>written if there is no test for it... That is the true spirit of TDD!
>
> Line coverage or path coverage? I can't figure out a valid counter
> example for line coverage, but 100% path coverage is very difficult
> to achieve and maintain.
>
> Kari
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Button | 1 Oct 2004 15:28

Re: 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Edwin Gabriel Castro | 1 Oct 2004 18:06

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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Feathers | 1 Oct 2004 19:48
Picon

Re: Re: Where to put test code

Edwin Gabriel Castro wrote:

> 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! :-)

Well, Brian's not going to toot his own horn on this one, but he's been 
doing TDD longer than about 99% of the developers who've tried it.  He's 
trained people in it for years, he's one of the best developers I know 
and he's worked with some of the best developers I've ever met.

Michael (that was just a compensatory toot.. something the conversation 
needed)

------------------------ 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
--------------------------------------------------------------------~->
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Button | 1 Oct 2004 21:08

Re: Re: Where to put test code


Edwin Gabriel Castro wrote:

> 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.

Edwin,

No harm, no foul. If we didn't feel passionate about this stuff, we 
wouldn't argue about it :)

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

Actually, long-time Linux user who recently swallowed the orange pill... 
(blue pill == blue badge == employee), (orange pill == consultant)

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Morgan | 1 Oct 2004 15:18
Picon

Tests for DAO


I am about to embark on refactoring an existing J2EE application at work.
The current application has a simple data access object that returns various
objects queried from a DB2 database.  There are unit tests associated with
this code now but they query against a development instance of the database
and assume that certain data already exists in the database.  What approaches
have others taken when writing unit tests for DAOs?

-- 
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomse by it"
    - Jon Ruskin

------------------------ 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
(Continue reading)

Permalink | Reply | 7 comments |

Gmane