Hi,

I've bought into the tdd idea but I'm still a novice in actually practicing tdd.

I've started a tdd learning project. After the first few steps I have collected
a couple of questions. Maybe you can help me and tell me if its reasonable what
I'm doing or if I'm completly off track. :)

The first step in my simple project was to download an rss feed using
java.net.URL. The first idea was to test the URL download, but then, it is a jdk
class and I don't want to test that but my own code. Don't I?

My code would be simply storing the feed content internally or throwing an
exception if the download fails. Because URL can't be mocked (at least with
mockito) I created an URL wrapper interface (FeedURL) and created two test
cases. One where the mocked FeedURL returns some rss feed xml and one where it
throws an exception.

That worked. But for the live code I would need a real implementation for
FeedURL. How would I tdd that into existance?

There is the issue that I don't want to setup a http server to put a real http
url in URL. file: & jar: have a the problem about properly locating the file or
jar when running the test.

After googling a bit it looked not to complicated to create my own in memory URL
protocol. It would call a method on a class and deliver its result. This way I
could store my test data in memory and use the real URL class. E.g. the url
bytes:iam/learning/tdd/Class#Method would call Method on class
iam.learning.tdd.Class.

So I started to tdd it. After the tests run, I started to refactor the main
method which was really dirty with several try/catches for all the stuff that
can happen when sing reflection.

I extracted 2 new classes. Since I extracted them during refactoring they do not
have any tests.

Is this ok? Or should I create new tests for them? Does this violate the rule
that each production code should be forced into existance by tests? Initially it
was, but the code in the class now has a number of small methods and so on. So
it is very different from the original code.

On another learning exercise I ended up with this scenario: On refactoring the
tested class and extracting a new class the tests that I wrote against the
original class would better fit to the extracted class now.

Would I move the tests to the new class?


--
Martin

Many similarities to my experience of TDD so far...

Some notes upon reading your story:

1. You _don't_ have to test everything. Especially testing third party APIs
is somewhat "vague" to me - if you really want to be sure they don't change,
for example you are using a library under heavy development, that might be a
good idea. But if you are using som Java SDK stable things, then those
integration tests (I call tests that excercise third party code integration
tests) are not so valuable to me.

2. Refactoring code into new classes, "microclasses", is a common pattern
for me too. That code is actually covered by tests, just not "class close"
tests. So I think they are OK, even without tests.

cya

2009/6/1 Martin Hauner <hauner@...>

>
>
> Hi,
>
> I've bought into the tdd idea but I'm still a novice in actually practicing
> tdd.
>
> I've started a tdd learning project. After the first few steps I have
> collected
> a couple of questions. Maybe you can help me and tell me if its reasonable
> what
> I'm doing or if I'm completly off track. :)
>
> The first step in my simple project was to download an rss feed using
> java.net.URL. The first idea was to test the URL download, but then, it is
> a jdk
> class and I don't want to test that but my own code. Don't I?
>
> My code would be simply storing the feed content internally or throwing an
> exception if the download fails. Because URL can't be mocked (at least with
>
> mockito) I created an URL wrapper interface (FeedURL) and created two test
> cases. One where the mocked FeedURL returns some rss feed xml and one where
> it
> throws an exception.
>
> That worked. But for the live code I would need a real implementation for
> FeedURL. How would I tdd that into existance?
>
> There is the issue that I don't want to setup a http server to put a real
> http
> url in URL. file: & jar: have a the problem about properly locating the
> file or
> jar when running the test.
>
> After googling a bit it looked not to complicated to create my own in
> memory URL
> protocol. It would call a method on a class and deliver its result. This
> way I
> could store my test data in memory and use the real URL class. E.g. the url
>
> bytes:iam/learning/tdd/Class#Method would call Method on class
> iam.learning.tdd.Class.
>
> So I started to tdd it. After the tests run, I started to refactor the main
>
> method which was really dirty with several try/catches for all the stuff
> that
> can happen when sing reflection.
>
> I extracted 2 new classes. Since I extracted them during refactoring they
> do not
> have any tests.
>
> Is this ok? Or should I create new tests for them? Does this violate the
> rule
> that each production code should be forced into existance by tests?
> Initially it
> was, but the code in the class now has a number of small methods and so on.
> So
> it is very different from the original code.
>
> On another learning exercise I ended up with this scenario: On refactoring
> the
> tested class and extracting a new class the tests that I wrote against the
> original class would better fit to the extracted class now.
>
> Would I move the tests to the new class?
>
> --
> Martin
>
>



--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english


[Non-text portions of this message have been removed]

Some good problems to work on as you learn TDD are the Euler problems:
http://projecteuler.net/

You can also check out the bowling game kata:
http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

I'm planning to post some info about katafication of the first few
Euler problems based on numerous TDD exercises we've done with them at
NimblePros.com when I have a chance.

Steve
Blog: http://SteveSmithBlog.com/


On Mon, Jun 1, 2009 at 10:17 AM, Olof Bjarnason
<olof.bjarnason@...> wrote:
>
>
> Many similarities to my experience of TDD so far...
>
> Some notes upon reading your story:
>
> 1. You _don't_ have to test everything. Especially testing third party APIs
> is somewhat "vague" to me - if you really want to be sure they don't change,
> for example you are using a library under heavy development, that might be a
> good idea. But if you are using som Java SDK stable things, then those
> integration tests (I call tests that excercise third party code integration
> tests) are not so valuable to me.
>
> 2. Refactoring code into new classes, "microclasses", is a common pattern
> for me too. That code is actually covered by tests, just not "class close"
> tests. So I think they are OK, even without tests.
>
> cya
>
> 2009/6/1 Martin Hauner <hauner@...>
>
>>
>>
>> Hi,
>>
>> I've bought into the tdd idea but I'm still a novice in actually
>> practicing
>> tdd.
>>
>> I've started a tdd learning project. After the first few steps I have
>> collected
>> a couple of questions. Maybe you can help me and tell me if its reasonable
>> what
>> I'm doing or if I'm completly off track. :)
>>
>> The first step in my simple project was to download an rss feed using
>> java.net.URL. The first idea was to test the URL download, but then, it is
>> a jdk
>> class and I don't want to test that but my own code. Don't I?
>>
>> My code would be simply storing the feed content internally or throwing an
>> exception if the download fails. Because URL can't be mocked (at least
>> with
>>
>> mockito) I created an URL wrapper interface (FeedURL) and created two test
>> cases. One where the mocked FeedURL returns some rss feed xml and one
>> where
>> it
>> throws an exception.
>>
>> That worked. But for the live code I would need a real implementation for
>> FeedURL. How would I tdd that into existance?
>>
>> There is the issue that I don't want to setup a http server to put a real
>> http
>> url in URL. file: & jar: have a the problem about properly locating the
>> file or
>> jar when running the test.
>>
>> After googling a bit it looked not to complicated to create my own in
>> memory URL
>> protocol. It would call a method on a class and deliver its result. This
>> way I
>> could store my test data in memory and use the real URL class. E.g. the
>> url
>>
>> bytes:iam/learning/tdd/Class#Method would call Method on class
>> iam.learning.tdd.Class.
>>
>> So I started to tdd it. After the tests run, I started to refactor the
>> main
>>
>> method which was really dirty with several try/catches for all the stuff
>> that
>> can happen when sing reflection.
>>
>> I extracted 2 new classes. Since I extracted them during refactoring they
>> do not
>> have any tests.
>>
>> Is this ok? Or should I create new tests for them? Does this violate the
>> rule
>> that each production code should be forced into existance by tests?
>> Initially it
>> was, but the code in the class now has a number of small methods and so
>> on.
>> So
>> it is very different from the original code.
>>
>> On another learning exercise I ended up with this scenario: On refactoring
>> the
>> tested class and extracting a new class the tests that I wrote against the
>> original class would better fit to the extracted class now.
>>
>> Would I move the tests to the new class?
>>
>> --
>> Martin
>>
>>
>
> --
> twitter.com/olofb
> olofb.wordpress.com
> olofb.wordpress.com/tag/english
>
> [Non-text portions of this message have been removed]
>
>



--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

Not much opportunity for refactoring...

-----Original Message-----
From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Steven Gordon
Sent: 31 May 2009 17:26
To: testdrivendevelopment@yahoogroups.com
Subject: Re: [TDD] test

green

On Sun, May 31, 2009 at 8:08 AM, Brian Noyes <brian.noyes@...> wrote:
>
>
> --
> -----------------------------------------
> Brian Noyes
> Chief Architect, IDesign Inc
> Microsoft Regional Director / MVP
> http://www.idesign.net
> +1 703-447-3712
> -----------------------------------------
>


------------------------------------

Yahoo! Groups Links

Martin,

It sounds as though you're going along nicely. I'd echo Olof and say if you find
new classes while refactoring, you don't need to create explicit tests for them.

My other input would be to get away from live feeds as quickly as you can. Just
one or two "integration" tests, and the rest should be isolated from the real
world.

I have another practice that helps me sometimes - not really TDD - create a
simple version of the real application that uses the growing body of code and
run that from time to time - it's usually instructive and revealing.

John D.

-----Original Message-----
From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Martin Hauner
Sent: 01 June 2009 15:29
To: testdrivendevelopment@yahoogroups.com
Subject: [TDD] Practicing tdd..

Hi,

I've bought into the tdd idea but I'm still a novice in actually practicing tdd.

I've started a tdd learning project. After the first few steps I have collected
a couple of questions. Maybe you can help me and tell me if its reasonable what
I'm doing or if I'm completly off track. :)

The first step in my simple project was to download an rss feed using
java.net.URL. The first idea was to test the URL download, but then, it is a jdk
class and I don't want to test that but my own code. Don't I?

My code would be simply storing the feed content internally or throwing an
exception if the download fails. Because URL can't be mocked (at least with
mockito) I created an URL wrapper interface (FeedURL) and created two test
cases. One where the mocked FeedURL returns some rss feed xml and one where it
throws an exception.

That worked. But for the live code I would need a real implementation for
FeedURL. How would I tdd that into existance?

There is the issue that I don't want to setup a http server to put a real http
url in URL. file: & jar: have a the problem about properly locating the file or
jar when running the test.

After googling a bit it looked not to complicated to create my own in memory URL
protocol. It would call a method on a class and deliver its result. This way I
could store my test data in memory and use the real URL class. E.g. the url
bytes:iam/learning/tdd/Class#Method would call Method on class
iam.learning.tdd.Class.

So I started to tdd it. After the tests run, I started to refactor the main
method which was really dirty with several try/catches for all the stuff that
can happen when sing reflection.

I extracted 2 new classes. Since I extracted them during refactoring they do not
have any tests.

Is this ok? Or should I create new tests for them? Does this violate the rule
that each production code should be forced into existance by tests? Initially it
was, but the code in the class now has a number of small methods and so on. So
it is very different from the original code.

On another learning exercise I ended up with this scenario: On refactoring the
tested class and extracting a new class the tests that I wrote against the
original class would better fit to the extracted class now.

Would I move the tests to the new class?


--
Martin


------------------------------------

Yahoo! Groups Links

Hi,

On 02.06.2009 8:45 Uhr, Donaldson, John (GEO) wrote:
> Martin,
>
> It sounds as though you're going along nicely. I'd echo Olof and say if
> you find new classes while refactoring, you don't need to create
> explicit tests for them.
>
> My other input would be to get away from live feeds as quickly as you
> can. Just one or two "integration" tests, and the rest should be
> isolated from the real world.

How do you organize your test code? I like to separate the production code and
test into different folders but in the same (java) package. Where do you place
the "integration" tests? Simply along the "unit" tests or in another folder?

> I have another practice that helps me sometimes - not really TDD -
> create a simple version of the real application that uses the growing
> body of code and run that from time to time - it's usually instructive
> and revealing.
>
> John D.

Thanks for the feedback :)

--
Martin

Martin,

> How do you organize your test code? I like to separate the production code and
> test into different folders but in the same (java) package. Where do you place
> the "integration" tests? Simply along the "unit" tests or in another folder?

Good questions.

I have a separate .NET project for my test suite and a bunch of projects for my
code (it will depend a bit on what architecture I've got - for example with MVP
I may have three separate projects plus something to hold interfaces. But there
are many ways to organize this and I don't feel very strict.

For real integration tests I'll use a separate project. But for the example
we're talking about, I'd probably keep everything together to start with. The
real reason to split things up, I think, will be how fast your tests run. If
they all run fast, then run them all! But likely the "integration" tests will
run slowly.

John D.


-----Original Message-----
From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Martin Hauner
Sent: 02 June 2009 21:04
To: testdrivendevelopment@yahoogroups.com
Subject: Re: [TDD] Practicing tdd..

Hi,

On 02.06.2009 8:45 Uhr, Donaldson, John (GEO) wrote:
> Martin,
>
> It sounds as though you're going along nicely. I'd echo Olof and say if
> you find new classes while refactoring, you don't need to create
> explicit tests for them.
>
> My other input would be to get away from live feeds as quickly as you
> can. Just one or two "integration" tests, and the rest should be
> isolated from the real world.

How do you organize your test code? I like to separate the production code and
test into different folders but in the same (java) package. Where do you place
the "integration" tests? Simply along the "unit" tests or in another folder?

> I have another practice that helps me sometimes - not really TDD -
> create a simple version of the real application that uses the growing
> body of code and run that from time to time - it's usually instructive
> and revealing.
>
> John D.

Thanks for the feedback :)

--
Martin


------------------------------------

Yahoo! Groups Links

Just to add,



There might come a point in time in which the number of test will become
just too big to handle all of them in a single project.

When that happens a common solution is to split the tests to several
projects the same way the production code is split.

That is for each production project there's a parallel test project.



In many cases I saw the same logic dictates an identical folders structure
on the disk where the production folder tree was duplicated for tests and
each test suite is stored according to the class under tests location.



Lior







From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Donaldson, John
(GEO)
Sent: Wednesday, June 03, 2009 12:16 AM
To: testdrivendevelopment@yahoogroups.com
Subject: RE: [TDD] Practicing tdd..

Martin,

> How do you organize your test code? I like to separate the production code
and
> test into different folders but in the same (java) package. Where do you
place
> the "integration" tests? Simply along the "unit" tests or in another
folder?

Good questions.

I have a separate .NET project for my test suite and a bunch of projects for
my code (it will depend a bit on what architecture I've got - for example
with MVP I may have three separate projects plus something to hold
interfaces. But there are many ways to organize this and I don't feel very
strict.

For real integration tests I'll use a separate project. But for the example
we're talking about, I'd probably keep everything together to start with.
The real reason to split things up, I think, will be how fast your tests
run. If they all run fast, then run them all! But likely the "integration"
tests will run slowly.

John D.

-----





[Non-text portions of this message have been removed]

I'm seeing in this list and on twitter people - new to TDD - calling TDD
something that's just "I'm writing automated tests" and most of times tests for
old cold.



While it's not strictly TDD is a good thing - if they can afford, of course. I
propose calling that TDR - Test Driven Refactoring.


[Non-text portions of this message have been removed]

I'll rewrite some sentences I found awful when I read myself:

I'm seeing people in this list and on twitter - people new to TDD - calling
"TDD" something that's just "I'm writing automated tests". And most of times
tests for old cold.

While that's not strictly TDD, that's is still a good thing for they do - if
they can afford it, of course. I propose calling that TDR - Test Driven
Refactoring.

On Wed, Jun 3, 2009 at 12:45 PM, osias <osiasjota@...> wrote:
>
>
>
>
> I'm seeing in this list and on twitter people - new to TDD - calling TDD
> something that's just "I'm writing automated tests" and most of times tests
> for old cold.
>
> While it's not strictly TDD is a good thing - if they can afford, of course.
> I propose calling that TDR - Test Driven Refactoring.
>

I propose we now call it Spicy Barbecue Chicken Wings (SBBQCW). It
bears no relation to anything except the fact that I happen to like
spicy barbecue chicken wings.

Seriously, though, not writing tests at all is unprofessional,
irresponsible, and retarded. Simply writing tests is part of software
development and doesn't need it's own special acronym (How about Test
Your Code, Duh? TYCD)

Further, given that simply not writing tests is unprofessional,
irresponsible, and retarded, refactoring without tests is
super-ultra-mega-retarded.

TDD is Test First + Continuous Refactoring. TDD + Refactoring is
redundant. If someone says, "I do TDD." Simply ask them, "Do you write
the tests first?" That's your first clue. Then ask them, "What do you
do after you've written the test." If the answer is not something
resembling "Make the test pass then refactor," then you know that they
are not in fact doing TDD. Beyond that I don't know what to call
whatever it is they are doing, nor do I care.

Hi Adam,

I propose we now call it Spicy Barbecue Chicken Wings (SBBQCW). It bears no
> relation to anything except the fact that I happen to like spicy barbecue
> chicken wings.
>

What's next? An acceptance test tool called Cucumber?

Then again, my family has a tradition of naming things after food. My
grandfather had a Bay Lynx that my six-year-old cousin named Fudge.

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com


[Non-text portions of this message have been removed]

2009/6/3 Osias Jota <osiasjota@...>
>
>
> I'll rewrite some sentences I found awful when I read myself:
>
> I'm seeing people in this list and on twitter - people new to TDD - calling
> "TDD" something that's just "I'm writing automated tests". And most of times
> tests for old cold.
>
> While that's not strictly TDD, that's is still a good thing for they do - if
> they can afford it, of course. I propose calling that TDR - Test Driven
> Refactoring.

In the Michael Feathers "Working Effictively with Legacy Code"-sense you mean?

I
>
>
>


--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota <osiasjota@...> wrote:
>
>
> I'll rewrite some sentences I found awful when I read myself:
>
> I'm seeing people in this list and on twitter - people new to TDD - calling
> "TDD" something that's just "I'm writing automated tests". And most of times
> tests for old cold.
>
> While that's not strictly TDD, that's is still a good thing for they do - if
> they can afford it, of course. I propose calling that TDR - Test Driven
> Refactoring.
>

Except that we don't write tests so that we can refactor. It is at
best a tertiary reason.

In the context of TDD we write tests so that we have an executable
specification of what our code is supposed to do which evolves
alongside the code itself and can be used to prove that the code
always works regardless of what we do to it (Which does include
refactoring, but also adding additional features, fixing bugs, etc.)
Refactoring is an inextricable part of TDD but it is not a goal in
itself.

Outside of TDD we write tests to establish if/how/why the code works.
Again, refactoring is not a primary goal. It is exceptionally
dangerous to attempt to refactor working code without tests, but then
it is also exceptionally dangerous to do any of the other things (Add
features, fix bugs, etc.) We refactor in order to facilitate change,
but refactoring is just the technique not the goal.

I commend all those who have been inspired by TDD to write automated
tests for their existing code. However, what they are doing is not TDD
and they don't need a special acronym to help them feel like part of
the club. The club is open to them. If they want to join they just
need to follow three simple rules...

2009/6/4 Adam Sroka <adam.sroka@...>:
>
>
> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota <osiasjota@...> wrote:
>>
>>
>> I'll rewrite some sentences I found awful when I read myself:
>>
>> I'm seeing people in this list and on twitter - people new to TDD -
>> calling
>> "TDD" something that's just "I'm writing automated tests". And most of
>> times
>> tests for old cold.
>>
>> While that's not strictly TDD, that's is still a good thing for they do -
>> if
>> they can afford it, of course. I propose calling that TDR - Test Driven
>> Refactoring.
>>
>
> Except that we don't write tests so that we can refactor. It is at
> best a tertiary reason.

Um, that is not strictly true ;)

While I think it is hard, I do tend to try at least to write tests to
be able to refactor legacy code.
(but in 90% of the cases it is too hard so I just refactor in
tiny-tiny steps and try to introduce new classes via TDD)

>
> In the context of TDD we write tests so that we have an executable
> specification of what our code is supposed to do which evolves
> alongside the code itself and can be used to prove that the code
> always works regardless of what we do to it (Which does include
> refactoring, but also adding additional features, fixing bugs, etc.)
> Refactoring is an inextricable part of TDD but it is not a goal in
> itself.
>
> Outside of TDD we write tests to establish if/how/why the code works.
> Again, refactoring is not a primary goal. It is exceptionally
> dangerous to attempt to refactor working code without tests, but then
> it is also exceptionally dangerous to do any of the other things (Add
> features, fix bugs, etc.) We refactor in order to facilitate change,
> but refactoring is just the technique not the goal.
>
> I commend all those who have been inspired by TDD to write automated
> tests for their existing code. However, what they are doing is not TDD
> and they don't need a special acronym to help them feel like part of
> the club. The club is open to them. If they want to join they just
> need to follow three simple rules...
>



--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
<olof.bjarnason@...> wrote:
>
>
> 2009/6/4 Adam Sroka <adam.sroka@...>:
>
>>
>>
>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota <osiasjota@...> wrote:
>>>
>>>
>>> I'll rewrite some sentences I found awful when I read myself:
>>>
>>> I'm seeing people in this list and on twitter - people new to TDD -
>>> calling
>>> "TDD" something that's just "I'm writing automated tests". And most of
>>> times
>>> tests for old cold.
>>>
>>> While that's not strictly TDD, that's is still a good thing for they do -
>>> if
>>> they can afford it, of course. I propose calling that TDR - Test Driven
>>> Refactoring.
>>>
>>
>> Except that we don't write tests so that we can refactor. It is at
>> best a tertiary reason.
>
> Um, that is not strictly true ;)
>
> While I think it is hard, I do tend to try at least to write tests to
> be able to refactor legacy code.
> (but in 90% of the cases it is too hard so I just refactor in
> tiny-tiny steps and try to introduce new classes via TDD)
>

Really? You write tests /so that/ you can refactor? There isn't a more
significant reason underlying that? Why do you want to refactor? For
sport?

2009/6/4 Adam Sroka <adam.sroka@...>:
>
>
> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
> <olof.bjarnason@...> wrote:
>>
>>
>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>
>>>
>>>
>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota <osiasjota@...> wrote:
>>>>
>>>>
>>>> I'll rewrite some sentences I found awful when I read myself:
>>>>
>>>> I'm seeing people in this list and on twitter - people new to TDD -
>>>> calling
>>>> "TDD" something that's just "I'm writing automated tests". And most of
>>>> times
>>>> tests for old cold.
>>>>
>>>> While that's not strictly TDD, that's is still a good thing for they do
>>>> -
>>>> if
>>>> they can afford it, of course. I propose calling that TDR - Test Driven
>>>> Refactoring.
>>>>
>>>
>>> Except that we don't write tests so that we can refactor. It is at
>>> best a tertiary reason.
>>
>> Um, that is not strictly true ;)
>>
>> While I think it is hard, I do tend to try at least to write tests to
>> be able to refactor legacy code.
>> (but in 90% of the cases it is too hard so I just refactor in
>> tiny-tiny steps and try to introduce new classes via TDD)
>>
>
> Really? You write tests /so that/ you can refactor? There isn't a more
> significant reason underlying that? Why do you want to refactor? For
> sport?

OK I'll try to explain in a little more detail.

<---
Say the system has close-to-no-tests (a common situation sadly..). A
so-called legacy-system.

And I am given the task to fix a bug in function A.

To do that, I have to understand how the function works.
Unfortunately, the function is long and unwieldy, and generally hard
to grokk.

Fortunately, the function has just two inputs and returns a single
int. So I can write some tests to cover the function.

When I've done that, I dear to refactor the function a little more
than I did without any tests.
--->

>



--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

On Thu, Jun 4, 2009 at 1:43 AM, Olof Bjarnason <olof.bjarnason@...> wrote:
>
>
> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>
>>
>> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
>> <olof.bjarnason@...> wrote:
>>>
>>>
>>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>
>>>>
>>>>
>>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota <osiasjota@...> wrote:
>>>>>
>>>>>
>>>>> I'll rewrite some sentences I found awful when I read myself:
>>>>>
>>>>> I'm seeing people in this list and on twitter - people new to TDD -
>>>>> calling
>>>>> "TDD" something that's just "I'm writing automated tests". And most of
>>>>> times
>>>>> tests for old cold.
>>>>>
>>>>> While that's not strictly TDD, that's is still a good thing for they do
>>>>> -
>>>>> if
>>>>> they can afford it, of course. I propose calling that TDR - Test Driven
>>>>> Refactoring.
>>>>>
>>>>
>>>> Except that we don't write tests so that we can refactor. It is at
>>>> best a tertiary reason.
>>>
>>> Um, that is not strictly true ;)
>>>
>>> While I think it is hard, I do tend to try at least to write tests to
>>> be able to refactor legacy code.
>>> (but in 90% of the cases it is too hard so I just refactor in
>>> tiny-tiny steps and try to introduce new classes via TDD)
>>>
>>
>> Really? You write tests /so that/ you can refactor? There isn't a more
>> significant reason underlying that? Why do you want to refactor? For
>> sport?
>
> OK I'll try to explain in a little more detail.
>
> <---
> Say the system has close-to-no-tests (a common situation sadly..). A
> so-called legacy-system.
>
> And I am given the task to fix a bug in function A.
>
> To do that, I have to understand how the function works.
> Unfortunately, the function is long and unwieldy, and generally hard
> to grokk.
>
> Fortunately, the function has just two inputs and returns a single
> int. So I can write some tests to cover the function.
>
> When I've done that, I dear to refactor the function a little more
> than I did without any tests.
> --->
>

My point is that your test is not driving your refactoring. Your test
is driving your bug fix. It might be driving your design/development
but it is not really TDD since the code existed before (and without)
the test.

You will refactor to simplify your design, and doing so will make it
possible (or at least easier) to implement your fix. That is how not
why.

I think that calling it "TDR" is both misleading and an attempt to
give special status to what should be considered an exception.

Adam Sroka skrev:
> On Thu, Jun 4, 2009 at 1:43 AM, Olof Bjarnason <olof.bjarnason@...>
wrote:
>>
>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>
>>> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
>>> <olof.bjarnason@...> wrote:
>>>>
>>>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>>
>>>>>
>>>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota <osiasjota@...> wrote:
>>>>>>
>>>>>> I'll rewrite some sentences I found awful when I read myself:
>>>>>>
>>>>>> I'm seeing people in this list and on twitter - people new to TDD -
>>>>>> calling
>>>>>> "TDD" something that's just "I'm writing automated tests". And most of
>>>>>> times
>>>>>> tests for old cold.
>>>>>>
>>>>>> While that's not strictly TDD, that's is still a good thing for they do
>>>>>> -
>>>>>> if
>>>>>> they can afford it, of course. I propose calling that TDR - Test Driven
>>>>>> Refactoring.
>>>>>>
>>>>> Except that we don't write tests so that we can refactor. It is at
>>>>> best a tertiary reason.
>>>> Um, that is not strictly true ;)
>>>>
>>>> While I think it is hard, I do tend to try at least to write tests to
>>>> be able to refactor legacy code.
>>>> (but in 90% of the cases it is too hard so I just refactor in
>>>> tiny-tiny steps and try to introduce new classes via TDD)
>>>>
>>> Really? You write tests /so that/ you can refactor? There isn't a more
>>> significant reason underlying that? Why do you want to refactor? For
>>> sport?
>> OK I'll try to explain in a little more detail.
>>
>> <---
>> Say the system has close-to-no-tests (a common situation sadly..). A
>> so-called legacy-system.
>>
>> And I am given the task to fix a bug in function A.
>>
>> To do that, I have to understand how the function works.
>> Unfortunately, the function is long and unwieldy, and generally hard
>> to grokk.
>>
>> Fortunately, the function has just two inputs and returns a single
>> int. So I can write some tests to cover the function.
>>
>> When I've done that, I dear to refactor the function a little more
>> than I did without any tests.
>> --->
>>
>
> My point is that your test is not driving your refactoring. Your test
> is driving your bug fix. It might be driving your design/development
> but it is not really TDD since the code existed before (and without)
> the test.

Well, wasn't that the point of the new acronyme?
Some way to say "I want to do TDD but I'm working legacy code and won't
get there for a while."

Especially on this Email list that would be usefull since there are a
lot of people that assume greenfield development whenever anyone asks a
question. Thus some way to distinguish "I'm working on a fully tested
project" from "I'm trying to handle a blob of legacy code in as close to
a TDD manner as I can accomplish"


//Samuel

On 4-Jun-09, at 6:04 AM, Samuel Åslund wrote:

> Adam Sroka skrev:
>> On Thu, Jun 4, 2009 at 1:43 AM, Olof Bjarnason
>> <olof.bjarnason@...> wrote:
>>>
>>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>>
>>>> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
>>>> <olof.bjarnason@...> wrote:
>>>>>
>>>>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>>>
>>>>>>
>>>>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota
>>>>>> <osiasjota@...> wrote:
>>>>>>>
>>>>>>> I'll rewrite some sentences I found awful when I read myself:
>>>>>>>
>>>>>>> I'm seeing people in this list and on twitter - people new to
>>>>>>> TDD -
>>>>>>> calling
>>>>>>> "TDD" something that's just "I'm writing automated tests".
>>>>>>> And most of
>>>>>>> times
>>>>>>> tests for old cold.
>>>>>>>
>>>>>>> While that's not strictly TDD, that's is still a good thing
>>>>>>> for they do
>>>>>>> -
>>>>>>> if
>>>>>>> they can afford it, of course. I propose calling that TDR -
>>>>>>> Test Driven
>>>>>>> Refactoring.
>>>>>>>
>>>>>> Except that we don't write tests so that we can refactor. It
>>>>>> is at
>>>>>> best a tertiary reason.
>>>>> Um, that is not strictly true ;)
>>>>>
>>>>> While I think it is hard, I do tend to try at least to write
>>>>> tests to
>>>>> be able to refactor legacy code.
>>>>> (but in 90% of the cases it is too hard so I just refactor in
>>>>> tiny-tiny steps and try to introduce new classes via TDD)
>>>>>
>>>> Really? You write tests /so that/ you can refactor? There isn't
>>>> a more
>>>> significant reason underlying that? Why do you want to refactor?
>>>> For
>>>> sport?
>>> OK I'll try to explain in a little more detail.
>>>
>>> <---
>>> Say the system has close-to-no-tests (a common situation sadly..). A
>>> so-called legacy-system.
>>>
>>> And I am given the task to fix a bug in function A.
>>>
>>> To do that, I have to understand how the function works.
>>> Unfortunately, the function is long and unwieldy, and generally hard
>>> to grokk.
>>>
>>> Fortunately, the function has just two inputs and returns a single
>>> int. So I can write some tests to cover the function.
>>>
>>> When I've done that, I dear to refactor the function a little more
>>> than I did without any tests.
>>> --->
>>>
>>
>> My point is that your test is not driving your refactoring. Your test
>> is driving your bug fix. It might be driving your design/development
>> but it is not really TDD since the code existed before (and without)
>> the test.
>
> Well, wasn't that the point of the new acronyme?
> Some way to say "I want to do TDD but I'm working legacy code and
> won't
> get there for a while."
>
> Especially on this Email list that would be usefull since there are a
> lot of people that assume greenfield development whenever anyone
> asks a
> question. Thus some way to distinguish "I'm working on a fully tested
> project" from "I'm trying to handle a blob of legacy code in as
> close to
> a TDD manner as I can accomplish"

Just to throw some more confusion into the mix -- I've found that to
newcomers to TDD, calling it Example-Driven Development (EDD, I
guess) seems to trigger the "a-ha" much faster than using the word
"test".  I really think that using the word "test" to identify what
we're doing is focusing too little on the purpose and too much on the
mechanism.

This especially helps when talking to developers who instinctively
get their hackles up when you insinuate that they should be writing
automated tests / doing anything strongly related to testing.

-Mike

>
>
> //Samuel
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

2009/6/4 Michael DiBernardo <mikedebo@...>:
>
>
>
> On 4-Jun-09, at 6:04 AM, Samuel Åslund wrote:
>
>> Adam Sroka skrev:
>>> On Thu, Jun 4, 2009 at 1:43 AM, Olof Bjarnason
>>> <olof.bjarnason@...> wrote:
>>>>
>>>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>>>
>>>>> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
>>>>> <olof.bjarnason@...> wrote:
>>>>>>
>>>>>> 2009/6/4 Adam Sroka <adam.sroka@...>:
>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota
>>>>>>> <osiasjota@...> wrote:
>>>>>>>>
>>>>>>>> I'll rewrite some sentences I found awful when I read myself:
>>>>>>>>
>>>>>>>> I'm seeing people in this list and on twitter - people new to
>>>>>>>> TDD -
>>>>>>>> calling
>>>>>>>> "TDD" something that's just "I'm writing automated tests".
>>>>>>>> And most of
>>>>>>>> times
>>>>>>>> tests for old cold.
>>>>>>>>
>>>>>>>> While that's not strictly TDD, that's is still a good thing
>>>>>>>> for they do
>>>>>>>> -
>>>>>>>> if
>>>>>>>> they can afford it, of course. I propose calling that TDR -
>>>>>>>> Test Driven
>>>>>>>> Refactoring.
>>>>>>>>
>>>>>>> Except that we don't write tests so that we can refactor. It
>>>>>>> is at
>>>>>>> best a tertiary reason.
>>>>>> Um, that is not strictly true ;)
>>>>>>
>>>>>> While I think it is hard, I do tend to try at least to write
>>>>>> tests to
>>>>>> be able to refactor legacy code.
>>>>>> (but in 90% of the cases it is too hard so I just refactor in
>>>>>> tiny-tiny steps and try to introduce new classes via TDD)
>>>>>>
>>>>> Really? You write tests /so that/ you can refactor? There isn't
>>>>> a more
>>>>> significant reason underlying that? Why do you want to refactor?
>>>>> For
>>>>> sport?
>>>> OK I'll try to explain in a little more detail.
>>>>
>>>> <---
>>>> Say the system has close-to-no-tests (a common situation sadly..). A
>>>> so-called legacy-system.
>>>>
>>>> And I am given the task to fix a bug in function A.
>>>>
>>>> To do that, I have to understand how the function works.
>>>> Unfortunately, the function is long and unwieldy, and generally hard
>>>> to grokk.
>>>>
>>>> Fortunately, the function has just two inputs and returns a single
>>>> int. So I can write some tests to cover the function.
>>>>
>>>> When I've done that, I dear to refactor the function a little more
>>>> than I did without any tests.
>>>> --->
>>>>
>>>
>>> My point is that your test is not driving your refactoring. Your test
>>> is driving your bug fix. It might be driving your design/development
>>> but it is not really TDD since the code existed before (and without)
>>> the test.
>>
>> Well, wasn't that the point of the new acronyme?
>> Some way to say "I want to do TDD but I'm working legacy code and
>> won't
>> get there for a while."
>>
>> Especially on this Email list that would be usefull since there are a
>> lot of people that assume greenfield development whenever anyone
>> asks a
>> question. Thus some way to distinguish "I'm working on a fully tested
>> project" from "I'm trying to handle a blob of legacy code in as
>> close to
>> a TDD manner as I can accomplish"
>
> Just to throw some more confusion into the mix -- I've found that to
> newcomers to TDD, calling it Example-Driven Development (EDD, I
> guess) seems to trigger the "a-ha" much faster than using the word
> "test". I really think that using the word "test" to identify what
> we're doing is focusing too little on the purpose and too much on the
> mechanism.

+1. I think the TDD/BDD camps should make a compromise and call it
EDD, I think that speaks up a lot more to what we are doing.

I keep thinking of TDD/BDD as "example driven development" and 90% of
my TDD/TDR efforts are coming up with examples. So it feels really
natural to speak of the whole deal as driving design/development via
concrete examples.

>
> This especially helps when talking to developers who instinctively
> get their hackles up when you insinuate that they should be writing
> automated tests / doing anything strongly related to testing.
>
> -Mike
>
>>
>>
>> //Samuel
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>



--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

>In the Michael Feathers "Working Effictively with Legacy Code"-sense you
>mean?

Didn't read it yet, but I think I can say yes. I'm working with a lot of
legacy code in the last months.

>I commend all those who have been inspired by TDD to write automated
>tests for their existing code. However, what they are doing is not TDD
>and they don't need a special acronym to help them feel like part of
>the club.


mmm... I was not thinking about making them feel part of the club, but about
politely telling them they're not... but  still incentivating to join.

>Just to throw some more confusion into the mix -- I've found that to
>newcomers to TDD, calling it Example-Driven Development (EDD, I
>guess) seems to trigger the "a-ha" much faster than using the word
>"test".

That seems - at first - a nice idea, but I think we can make "examples" for
untestable things. I'll think about it...

This is like the abortion debate. Instead of concentrating on the pragmatic
we instead argue on when a test should be conceived.

The issue with TDD is you need to have imaculate conception to fit in with
the purest.

I have written tests to refactor, so I could test whether something would
work without having to spin up the whole system with each change. To get
code to testable point you have to write tests for subsystems that fail so
you can get them to pass.

Concentrating on the fact you wrote code before tests is ignorant of the
fact that most code out in the wild gasp has no tests:)

Joshua Thomas
undev.spaces.live.com


On Thu, Jun 4, 2009 at 7:05 AM, Olof Bjarnason <olof.bjarnason@...>wrote:

>
>
> 2009/6/4 Michael DiBernardo <mikedebo@... <mikedebo%40gmail.com>>:
>
> >
> >
> >
> > On 4-Jun-09, at 6:04 AM, Samuel Åslund wrote:
> >
> >> Adam Sroka skrev:
> >>> On Thu, Jun 4, 2009 at 1:43 AM, Olof Bjarnason
> >>> <olof.bjarnason@... <olof.bjarnason%40gmail.com>> wrote:
> >>>>
> >>>> 2009/6/4 Adam Sroka <adam.sroka@... <adam.sroka%40gmail.com>>:
> >>>>>
> >>>>> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
> >>>>> <olof.bjarnason@... <olof.bjarnason%40gmail.com>> wrote:
> >>>>>>
> >>>>>> 2009/6/4 Adam Sroka <adam.sroka@... <adam.sroka%40gmail.com>
> >:
> >>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota
> >>>>>>> <osiasjota@... <osiasjota%40gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>> I'll rewrite some sentences I found awful when I read myself:
> >>>>>>>>
> >>>>>>>> I'm seeing people in this list and on twitter - people new to
> >>>>>>>> TDD -
> >>>>>>>> calling
> >>>>>>>> "TDD" something that's just "I'm writing automated tests".
> >>>>>>>> And most of
> >>>>>>>> times
> >>>>>>>> tests for old cold.
> >>>>>>>>
> >>>>>>>> While that's not strictly TDD, that's is still a good thing
> >>>>>>>> for they do
> >>>>>>>> -
> >>>>>>>> if
> >>>>>>>> they can afford it, of course. I propose calling that TDR -
> >>>>>>>> Test Driven
> >>>>>>>> Refactoring.
> >>>>>>>>
> >>>>>>> Except that we don't write tests so that we can refactor. It
> >>>>>>> is at
> >>>>>>> best a tertiary reason.
> >>>>>> Um, that is not strictly true ;)
> >>>>>>
> >>>>>> While I think it is hard, I do tend to try at least to write
> >>>>>> tests to
> >>>>>> be able to refactor legacy code.
> >>>>>> (but in 90% of the cases it is too hard so I just refactor in
> >>>>>> tiny-tiny steps and try to introduce new classes via TDD)
> >>>>>>
> >>>>> Really? You write tests /so that/ you can refactor? There isn't
> >>>>> a more
> >>>>> significant reason underlying that? Why do you want to refactor?
> >>>>> For
> >>>>> sport?
> >>>> OK I'll try to explain in a little more detail.
> >>>>
> >>>> <---
> >>>> Say the system has close-to-no-tests (a common situation sadly..). A
> >>>> so-called legacy-system.
> >>>>
> >>>> And I am given the task to fix a bug in function A.
> >>>>
> >>>> To do that, I have to understand how the function works.
> >>>> Unfortunately, the function is long and unwieldy, and generally hard
> >>>> to grokk.
> >>>>
> >>>> Fortunately, the function has just two inputs and returns a single
> >>>> int. So I can write some tests to cover the function.
> >>>>
> >>>> When I've done that, I dear to refactor the function a little more
> >>>> than I did without any tests.
> >>>> --->
> >>>>
> >>>
> >>> My point is that your test is not driving your refactoring. Your test
> >>> is driving your bug fix. It might be driving your design/development
> >>> but it is not really TDD since the code existed before (and without)
> >>> the test.
> >>
> >> Well, wasn't that the point of the new acronyme?
> >> Some way to say "I want to do TDD but I'm working legacy code and
> >> won't
> >> get there for a while."
> >>
> >> Especially on this Email list that would be usefull since there are a
> >> lot of people that assume greenfield development whenever anyone
> >> asks a
> >> question. Thus some way to distinguish "I'm working on a fully tested
> >> project" from "I'm trying to handle a blob of legacy code in as
> >> close to
> >> a TDD manner as I can accomplish"
> >
> > Just to throw some more confusion into the mix -- I've found that to
> > newcomers to TDD, calling it Example-Driven Development (EDD, I
> > guess) seems to trigger the "a-ha" much faster than using the word
> > "test". I really think that using the word "test" to identify what
> > we're doing is focusing too little on the purpose and too much on the
> > mechanism.
>
> +1. I think the TDD/BDD camps should make a compromise and call it
> EDD, I think that speaks up a lot more to what we are doing.
>
> I keep thinking of TDD/BDD as "example driven development" and 90% of
> my TDD/TDR efforts are coming up with examples. So it feels really
> natural to speak of the whole deal as driving design/development via
> concrete examples.
>
> >
> > This especially helps when talking to developers who instinctively
> > get their hackles up when you insinuate that they should be writing
> > automated tests / doing anything strongly related to testing.
> >
> > -Mike
> >
> >>
> >>
> >> //Samuel
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >
> >
>
> --
> twitter.com/olofb
> olofb.wordpress.com
> olofb.wordpress.com/tag/english
>
>
>


[Non-text portions of this message have been removed]

Um, trim out lines please?  This is extremely tiresome to read message after
message of everything quoted and lines getting broken up and having to scroll
way down to find substance.  You should only need to quote one of two previous
authors, not all of them.




________________________________
From: Olof Bjarnason <olof.bjarnason@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Thursday, June 4, 2009 7:05:26 AM
Subject: Re: [TDD] new acronym? TDR [2]





2009/6/4 Michael DiBernardo <mikedebo@gmail. com>:
>
>
>
> On 4-Jun-09, at 6:04 AM, Samuel Åslund wrote:
>
>> Adam Sroka skrev:
>>> On Thu, Jun 4, 2009 at 1:43 AM, Olof Bjarnason
>>> <olof.bjarnason@ gmail.com> wrote:
>>>>
>>>> 2009/6/4 Adam Sroka <adam.sroka@gmail. com>:
>>>>>
>>>>> On Thu, Jun 4, 2009 at 12:50 AM, Olof Bjarnason
>>>>> <olof.bjarnason@ gmail.com> wrote:
>>>>>>
>>>>>> 2009/6/4 Adam Sroka <adam.sroka@gmail. com>:
>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 3, 2009 at 12:59 PM, Osias Jota
>>>>>>> <osiasjota@gmail. com> wrote:
>>>>>>>>


       __________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get
it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

[Non-text portions of this message have been removed]

On Thu, Jun 4, 2009 at 3:04 AM, Samuel Åslund <samuel@...> wrote:
>
>
> Well, wasn't that the point of the new acronyme?
> Some way to say "I want to do TDD but I'm working legacy code and won't
> get there for a while."
>
> Especially on this Email list that would be usefull since there are a
> lot of people that assume greenfield development whenever anyone asks a
> question. Thus some way to distinguish "I'm working on a fully tested
> project" from "I'm trying to handle a blob of legacy code in as close to
> a TDD manner as I can accomplish"
>

I suppose that it might be useful. However, I still don't like "TDR".
Tests may "drive" my design but they don't "drive" my refactoring. My
refactoring is driven by the desire to keep the code simple and
concise. Nothing about the tests compels me to do that, although
having the tests makes it possible to show that the refactored code is
still correct.

I think of adding tests to legacy code as more of a quality control
and/or process stabilization task rather than a design task. Perhaps
"Quality Recovery Testing" (QRT)?

On Thu, Jun 4, 2009 at 3:24 AM, Michael DiBernardo <mikedebo@...> wrote:
>
> Just to throw some more confusion into the mix -- I've found that to
> newcomers to TDD, calling it Example-Driven Development (EDD, I
> guess) seems to trigger the "a-ha" much faster than using the word
> "test". I really think that using the word "test" to identify what
> we're doing is focusing too little on the purpose and too much on the
> mechanism.
>
> This especially helps when talking to developers who instinctively
> get their hackles up when you insinuate that they should be writing
> automated tests / doing anything strongly related to testing.
>

I like that. However, I prefer the term "Specification" as the BDD
folks say rather than "Example" since there is generally more to a
test/spec than just an example of use (An example that compiles and
runs but doesn't verify or assert anything is not sufficient for
TDD/BDD, for instance. Though such a thing is very useful to have in
your docs.)

Also, on a less serious note, EDD sounds a little too much like what
they keep trying to sell me pills for on TV and in my junk mail
folder. ;-)

On Thu, Jun 4, 2009 at 8:36 AM, Joshua Thomas <foreachdev@...> wrote:
>
>
> This is like the abortion debate. Instead of concentrating on the pragmatic
> we instead argue on when a test should be conceived.
>

I don't think we are arguing about when the tests should be conceived.
The definition of TDD is precise and fairly well understood. It hasn't
changed since the term was first introduced a decade ago.

> The issue with TDD is you need to have imaculate conception to fit in with
> the purest.
>

You can write tests whenever you want... or never. That is up to the
team you develop software with. You just shouldn't call it TDD unless
you are doing it the way we describe. The reason you shouldn't call it
TDD is explained well here:
http://martinfowler.com/bliki/SemanticDiffusion.html

> I have written tests to refactor, so I could test whether something would
> work without having to spin up the whole system with each change. To get
> code to testable point you have to write tests for subsystems that fail so
> you can get them to pass.
>

Good! :-)

> Concentrating on the fact you wrote code before tests is ignorant of the
> fact that most code out in the wild gasp has no tests:)
>

I am not advocating lynchings for the folks who don't do TDD. Do
whatever you want. I'm just saying that TDD is a specific form of
testing/design with specific rules and that we shouldn't abuse the
term nor should we spend a lot of time trying to introduce new terms
for things that aren't TDD. What we should be doing is advocating that
people do TDD/BDD while acknowledging that there are exceptional
circumstances where TDD cannot be easily applied.

Sometimes I'm doing sort of Test-Driven Refactoring, but in a different sense.
This is when I write an integration test first, make it pass with a quick and
dirty solution, and then want to refactor it into several components. Sure I've
got a 100% coverage by the initial test, but I want additional tests serve as
specs/examples.

For example, it is required that if a user is logged in, her name is displayed
at the main screen. From that requirement, I write a test that involves
registration, logging in, and checking the value of a certain label. Making it
pass is very simple, since we don't tests for invalid credentials.

Next, I decide to refactor it into three components: registration,
authentication, and the main screen. Naturally, it is better done with some
test-driving. This time, the tests would check for some inner state. For
example, I could test that after logging in, the Username value of a certain
object(say, User.Current) matches what was entered at the login screen, and
another test would check that the label's text matches this Username property.

This is how the tests drive my design: first, I see a test that is doing too
much (this particular test is too hard to setup), which leads me to refactoring,
and second, the additional tests point me to the right direction to refactor. If
I had only this first integration test, there will be no tests influencing my
design, thus no real TDD.

Later, when I see that these components should be refactored into smaller
classes, I might decide that I don't need any new tests, since they don't
correspond to any "features" and would make my design brittle.

ulu

--- In testdrivendevelopment@yahoogroups.com, "Osias Jota" <osiasjota@...>
wrote:
>
> I'll rewrite some sentences I found awful when I read myself:
>
> I'm seeing people in this list and on twitter - people new to TDD - calling
> "TDD" something that's just "I'm writing automated tests". And most of times
> tests for old cold.
>
> While that's not strictly TDD, that's is still a good thing for they do - if
> they can afford it, of course. I propose calling that TDR - Test Driven
> Refactoring.
>

On Wed, Jun 3, 2009 at 9:59 PM, Osias Jota <osiasjota@...> wrote:

> While that's not strictly TDD, that's is still a good thing for they do -
> if
> they can afford it, of course. I propose calling that TDR - Test Driven
> Refactoring.


I used the term Test-Driven Refactoring in my 2004 book, Refactoring to
Patterns.  It came up for a refactoring like this one:

http://www.industriallogic.com/xp/refactoring/implicitTreeWithComposite.html

In that case, we aren't extracting methods and doing normal refactoring
moves.  We're TDDing new code, then incrementally replacing old bits of code
with the newer (TDDed) code.  That old code has unit tests, so it usually
doesn't mean writing new tests for the old code.    The trick is to do this
TDR in small steps.  You TDD something primitive, get it being used in old
code and then repeat the TDD/old code replacement process until there is no
more old code.

Hope that helps.

--
best regards,
jk

Industrial Logic, Inc.
Joshua Kerievsky
Founder, Extreme Programmer & Coach
http://industriallogic.com
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

Are you a "Musician" or "Rock Star" Programmer?
http://industriallogic.com/elearning


[Non-text portions of this message have been removed]

Hello,
I am working on a project to introduce unit testing in order to
refactor and hopefully improve the actual codebase which is quite old,
large and messy. Much of the code I am interested in is C code,
located in large (sometimes very large) files, with deeply nested
dependencies.

In order to unit test that stuff, I need to "stub" most of the
function calls located in other libraries. That is, given some
function f in file code.c, I want to:
  - compile code.c to code.o (code.obj)
  - compile test.c to test.o (test.obj)
  - test f and only f
  - redo for other functions

Compiled object files have of course quite a lot of undefined symbols
which I do not plan to use anyway and which I then need to define to a
dummmy function. I managed to do some dirty things on linux with some
objdump, grep and sed to generate C code from a shared object still
containing undefined symbols, to produce a final executable with all
symboles defined.

But this is quite ugly and does not solve the problems of:
  - stubbing a function which is actually code by SUT, as I need to be
  aware of arguments and return types to generate meaningful code,
  - stubbing a function in the same compilation unit as the SUT.

For the latter problem, I can always try to chop files to break
internal dependencies at the cost of exposing things. But for the
former, I am a bit stuck. What I need is a general way to redefine
symbols in source code and ignore all the rest. Moreover, I need to do
this for several platforms: linux, solaris and NT.

Does anybody have ideas about how to do that ? I started to delve in
the arcanes of GNU ld and BFD, but I fear this shall be very time
consuming and quite brittle for "mere" unit tests.

Thanks in advance for feedback,
--
Arnaud Bailly, PhD
OQube - Software Engineering
http://www.oqube.com