Discussion:
How to unit test
Tunca Bergmen
2005-08-11 12:26:25 UTC
Permalink
Hi all,



First of all I want to introduce myself. I am a software developer from
Turkey. I am programming professionally since 1999. Currently, I mostly
develop in .NET using C#. I am very new to XP. I've just started applying
test first programming in one of my projects, using NUnit.



I am writing a simple OR mapper. I have a class that generates insert sql
according to metadata. First I wrote a test which knows the correct sql and
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates correct sql
string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?



Thanks,

Tunca Bergmen



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





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Michael Dubakov
2005-08-11 13:37:43 UTC
Permalink
On the first sight you may split SQL query and test it by parts.
For example, you can split columns, put them into array and make sure
that array has correct length. Or you can change your code to generate
columns in ordered way.

Michael
http://www.targetprocess.com
APM&BT Tool
Post by Tunca Bergmen
First of all I want to introduce myself. I am a software developer from
Turkey. I am programming professionally since 1999. Currently, I mostly
develop in .NET using C#. I am very new to XP. I've just started
applying
Post by Tunca Bergmen
test first programming in one of my projects, using NUnit.
I am writing a simple OR mapper. I have a class that generates
insert sql
Post by Tunca Bergmen
according to metadata. First I wrote a test which knows the correct
sql and
Post by Tunca Bergmen
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates
correct sql
Post by Tunca Bergmen
string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?
Thanks,
Tunca Bergmen
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-11 20:33:53 UTC
Permalink
Yes, I guess if you can't backtrack and properly test the parts that
make up the code under tests, that might be a good solution... I think I
wouldn't bother splitting it up though, and simply use
String.indexOf(String) to make sure I had my column name... not pretty
but will certainly fail if the code under test doesn't do what it should.

- Brill Pappin
Post by Michael Dubakov
On the first sight you may split SQL query and test it by parts.
For example, you can split columns, put them into array and make sure
that array has correct length. Or you can change your code to generate
columns in ordered way.
Michael
http://www.targetprocess.com
APM&BT Tool
Post by Tunca Bergmen
First of all I want to introduce myself. I am a software developer from
Turkey. I am programming professionally since 1999. Currently, I mostly
develop in .NET using C#. I am very new to XP. I've just started
applying
Post by Tunca Bergmen
test first programming in one of my projects, using NUnit.
I am writing a simple OR mapper. I have a class that generates
insert sql
Post by Tunca Bergmen
according to metadata. First I wrote a test which knows the correct
sql and
Post by Tunca Bergmen
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates
correct sql
Post by Tunca Bergmen
string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?
Thanks,
Tunca Bergmen
[Non-text portions of this message have been removed]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Chris Dollin
2005-08-11 13:45:22 UTC
Permalink
Post by Tunca Bergmen
First of all I want to introduce myself. I am a software developer from
Turkey. I am programming professionally since 1999. Currently, I mostly
develop in .NET using C#. I am very new to XP. I've just started applying
test first programming in one of my projects, using NUnit.
I am writing a simple OR mapper. I have a class that generates insert sql
according to metadata. First I wrote a test which knows the correct sql and
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates correct
sql string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?
Three (non-exhaustive) possibilities:

(a) dive down further and test the code that creates the /pieces/
of the final string. Have a weaker test for the composite
string (ie that the required substrings appear in it).

(b) Carve the generated SQL into pieces. For the bits that are
in "random" order, put them into a set, and compare with a
set of the expected pieces.

(c) Fix whatever is producing the random order in the generated
SQL.
--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Tunca Bergmen
2005-08-11 18:35:33 UTC
Permalink
Post by Chris Dollin
(a) dive down further and test the code that creates the /pieces/
of the final string. Have a weaker test for the composite
string (ie that the required substrings appear in it).
It sounds ok to some point but it is not enough. In my context, I am
dealing with a sql string which has a strict syntax. For example, one
of the strings below is correct, and the other is false, but they both
would pass this kind of test, which only looks for apperances/pieces
of substrings in the whole text.

1. INSERT INTO MyTable (ColumnA, ColumnB) VALUES ('ValueA', 'ValueB')
2. INSERT INTO MyTable (,ColumnA ColumnB) VALUES (,'ValueA','ValueB,)
Post by Chris Dollin
(b) Carve the generated SQL into pieces. For the bits that are
in "random" order, put them into a set, and compare with a
set of the expected pieces.
This still won't solve my syntax problem.





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2005-08-12 01:01:11 UTC
Permalink
Post by Tunca Bergmen
It sounds ok to some point but it is not enough. In my context, I am
dealing with a sql string which has a strict syntax. For example, one
of the strings below is correct, and the other is false, but they both
would pass this kind of test, which only looks for apperances/pieces
of substrings in the whole text.
1. INSERT INTO MyTable (ColumnA, ColumnB) VALUES ('ValueA', 'ValueB')
2. INSERT INTO MyTable (,ColumnA ColumnB) VALUES (,'ValueA','ValueB,)
Post by Chris Dollin
(b) Carve the generated SQL into pieces. For the bits that are
in "random" order, put them into a set, and compare with a
set of the expected pieces.
This still won't solve my syntax problem.
Seems to me that your problem has two parts ...

1. Does the list look like a well-formatted list;
2. Does the list contain exactly fields a, b, c in some order.

So maybe I'd test those two things ...

Ron Jeffries
www.XProgramming.com
Any errors you find in this are the work of Secret Villains,
whose mad schemes will soon be revealed. -- Wil McCarthy



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Chris Dollin
2005-08-12 09:29:05 UTC
Permalink
Post by Tunca Bergmen
Post by Chris Dollin
(a) dive down further and test the code that creates the /pieces/
of the final string. Have a weaker test for the composite
string (ie that the required substrings appear in it).
It sounds ok to some point but it is not enough. In my context, I am
dealing with a sql string which has a strict syntax. For example, one
of the strings below is correct, and the other is false, but they both
would pass this kind of test, which only looks for apperances/pieces
of substrings in the whole text.
1. INSERT INTO MyTable (ColumnA, ColumnB) VALUES ('ValueA', 'ValueB')
2. INSERT INTO MyTable (,ColumnA ColumnB) VALUES (,'ValueA','ValueB,)
Easy-peasy (may not be the best way).

Check "ColumnA" is in the text. Replace it with "X".
Check "ColumnB" is in the text. Replace it with "X".

Check "(X, X)" is in the text.

[Extend as appropriate.]

I suspect there's a much better solution. EG when I'm testing the
code that assembles `(ColumnA, ColumnB)` I'd check that given two
column strings X and Y it generates `(X, Y)`, etc - that test
doesn't need to care about ordering issues, it's just checking
for correct composition.
Post by Tunca Bergmen
Post by Chris Dollin
(b) Carve the generated SQL into pieces. For the bits that are
in "random" order, put them into a set, and compare with a
set of the expected pieces.
This still won't solve my syntax problem.
Why not? In the above example,

Slice out (ColumnA, ColumnB) from the whole string.
Strip ()
Find comma-separated pieces ColumnA and ColumnB
Stuff them into a set
Compare with expected set {ColumnA ColumnB}

Again, may not be the *best* way, but it does appear to be
*a* way.
--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2005-08-12 10:04:39 UTC
Permalink
Post by Chris Dollin
Post by Tunca Bergmen
1. INSERT INTO MyTable (ColumnA, ColumnB) VALUES ('ValueA', 'ValueB')
2. INSERT INTO MyTable (,ColumnA ColumnB) VALUES (,'ValueA','ValueB,)
Easy-peasy (may not be the best way).
Check "ColumnA" is in the text. Replace it with "X".
Check "ColumnB" is in the text. Replace it with "X".
Check "(X, X)" is in the text.
[Extend as appropriate.]
Exxxxcellent! Hits dead center the target I was vaguely pointing at.
Neat solution!

Ron Jeffries
www.XProgramming.com
Only the hand that erases can write the true thing. -- Meister Eckhart



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Tunca Bergmen
2005-08-12 10:19:20 UTC
Permalink
WOW!! This really is a brilliant solution. Thanks.
Post by Chris Dollin
Post by Tunca Bergmen
Post by Chris Dollin
(a) dive down further and test the code that creates
the /pieces/
Post by Chris Dollin
Post by Tunca Bergmen
Post by Chris Dollin
of the final string. Have a weaker test for the composite
string (ie that the required substrings appear in it).
It sounds ok to some point but it is not enough. In my context, I am
dealing with a sql string which has a strict syntax. For
example, one
Post by Chris Dollin
Post by Tunca Bergmen
of the strings below is correct, and the other is false, but
they both
Post by Chris Dollin
Post by Tunca Bergmen
would pass this kind of test, which only looks for
apperances/pieces
Post by Chris Dollin
Post by Tunca Bergmen
of substrings in the whole text.
1. INSERT INTO MyTable (ColumnA, ColumnB) VALUES
('ValueA', 'ValueB')
Post by Chris Dollin
Post by Tunca Bergmen
2. INSERT INTO MyTable (,ColumnA ColumnB) VALUES
(,'ValueA','ValueB,)
Post by Chris Dollin
Easy-peasy (may not be the best way).
Check "ColumnA" is in the text. Replace it with "X".
Check "ColumnB" is in the text. Replace it with "X".
Check "(X, X)" is in the text.
[Extend as appropriate.]
I suspect there's a much better solution. EG when I'm testing the
code that assembles `(ColumnA, ColumnB)` I'd check that given two
column strings X and Y it generates `(X, Y)`, etc - that test
doesn't need to care about ordering issues, it's just checking
for correct composition.
Post by Tunca Bergmen
Post by Chris Dollin
(b) Carve the generated SQL into pieces. For the bits that are
in "random" order, put them into a set, and compare with a
set of the expected pieces.
This still won't solve my syntax problem.
Why not? In the above example,
Slice out (ColumnA, ColumnB) from the whole string.
Strip ()
Find comma-separated pieces ColumnA and ColumnB
Stuff them into a set
Compare with expected set {ColumnA ColumnB}
Again, may not be the *best* way, but it does appear to be
*a* way.
--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2005-08-11 16:27:02 UTC
Permalink
Post by Tunca Bergmen
I am writing a simple OR mapper. I have a class that generates insert sql
according to metadata. First I wrote a test which knows the correct sql and
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates correct sql
string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?
Would it be harmful to the application if you sorted the column
names in alphanumeric order?

Ron Jeffries
www.XProgramming.com
Show me the features!



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Tunca Bergmen
2005-08-11 18:23:03 UTC
Permalink
First of all, thanks for all replies;
Post by Ron Jeffries
Would it be harmful to the application if you sorted the column
names in alphanumeric order?
Ron Jeffries
www.XProgramming.com
Show me the features!
This was the first thing that crossed my mind but I think sorting
columns provides no benefit for my algorithm except for making the
test simpler but it has two main costs:

1. It would somehow decrease the performance.
2. It would complicate the algorithm.

As I said before, I am very new to these practices. One thing I
wonder about the philosophy of XP is, when we say the term "test
driven development", do we mean that we should change our
programming logic in order to make our testing logic simpler, even
when it has negative effects on the programming logic?

Thanks,
Tunca Bergmen





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-11 20:25:41 UTC
Permalink
Tunca Bergmen wrote:
[...]
Post by Tunca Bergmen
As I said before, I am very new to these practices. One thing I
wonder about the philosophy of XP is, when we say the term "test
driven development", do we mean that we should change our
programming logic in order to make our testing logic simpler, even
when it has negative effects on the programming logic?
The sort answer is yes, change your "programming logic" but don't do it
*just* so you can test. If you do the simplest thing possible in your
code, your test should also be simple and it follows that if you make
the test simple, you code should follow suit (only doing exactly what is
required to pass the tests).

Actually (I can't stress enough) writing the test doesn't have negative
effects on the actual code under test (or shouldn't if your being good
about how you write your tests)... I can't name one single case where I
wouldn't want the test in place... but I can give you a multitude where
not writing the tests has a negative effect.
That said, it does mean you have very *different* code that what you
would have written had you not used TDD and I find that a lot of folks
new to TDD think of those differences as negative.

There are a whole slew of theories and practices that work with TDD
about why that new code structure is actually better, but I don't think
I could sum it all up in a single message or even sell you on the fact
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html

IMO - As a rule well written tests will guide you down the path to agile
code all by themselves and is the cornerstone of Agile development
practices.

- Brill Pappin




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2005-08-12 01:17:25 UTC
Permalink
Post by Brill Pappin
There are a whole slew of theories and practices that work with TDD
about why that new code structure is actually better, but I don't think
I could sum it all up in a single message or even sell you on the fact
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html
At a guess, his name might be William Caputo. I know a guy by that
name ... ;->

Ron Jeffries
www.XProgramming.com
There is no art without intention. -- Duke Ellington



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-12 05:31:35 UTC
Permalink
[...]
Post by Ron Jeffries
Post by Brill Pappin
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html
At a guess, his name might be William Caputo. I know a guy by that
name ... ;->
<chuckle> I almost took a guess but you never know :)

He has some other interesting articles for those looking for reading
material.

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
William E Caputo
2005-08-13 16:48:20 UTC
Permalink
[...]
Post by Ron Jeffries
Post by Brill Pappin
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html
At a guess, his name might be William Caputo. I know a guy by that
name ... ;->
I seem to have heard it somewhere before too... I wonder if we are
related.
Post by Ron Jeffries
<chuckle> I almost took a guess but you never know :)
Never can be too sure, I agree. ;-)
Post by Ron Jeffries
He has some other interesting articles for those looking for reading
material.
Thanks for the positive feedback. :-)

Best,
Bill

William E. Caputo
http://www.williamcaputo.com
ThoughtWorks, Inc.
--------





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Tunca Bergmen
2005-08-12 10:31:12 UTC
Permalink
The article was enlightening. Now I understand what was wrong about
my tests. I think, I need to read more about TDD. I am going to
order a book from Amazon. Is there any that you could recommend?

Thanks for your help,
Tunca
Post by Brill Pappin
The sort answer is yes, change your "programming logic" but don't do it
*just* so you can test. If you do the simplest thing possible in your
code, your test should also be simple and it follows that if you make
the test simple, you code should follow suit (only doing exactly what is
required to pass the tests).
Actually (I can't stress enough) writing the test doesn't have
negative
Post by Brill Pappin
effects on the actual code under test (or shouldn't if your being good
about how you write your tests)... I can't name one single case where I
wouldn't want the test in place... but I can give you a multitude where
not writing the tests has a negative effect.
That said, it does mean you have very *different* code that what you
would have written had you not used TDD and I find that a lot of folks
new to TDD think of those differences as negative.
There are a whole slew of theories and practices that work with TDD
about why that new code structure is actually better, but I don't think
I could sum it all up in a single message or even sell you on the fact
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html
IMO - As a rule well written tests will guide you down the path to agile
code all by themselves and is the cornerstone of Agile development
practices.
- Brill Pappin
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-12 14:40:40 UTC
Permalink
There is always Kent Becks "Test Driven Development: By Example". It's a
pretty good "Classic" as Agile books go.

I think the article you read though pretty much sums up where most
developers go wrong, however reading more will help, and nothing beats
practice :)

- Brill Pappin
Post by Tunca Bergmen
The article was enlightening. Now I understand what was wrong about
my tests. I think, I need to read more about TDD. I am going to
order a book from Amazon. Is there any that you could recommend?
Thanks for your help,
Tunca
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim McMaster
2005-08-12 15:07:11 UTC
Permalink
Post by Brill Pappin
There is always Kent Becks "Test Driven Development: By
Example". It's a
pretty good "Classic" as Agile books go.
"TDD by Example" is very good. I also like "Test-Driven Development: A
Practical Guide" by David Astels, and "Pragmatic Unit Testing in Java with
Junit" by Andrew Hunt and Dave Thomas.
--
Jim McMaster
mailto:***@comcast.net







To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Mark Wilden
2005-08-12 18:25:01 UTC
Permalink
Post by Brill Pappin
There is always Kent Becks "Test Driven Development: By Example". It's a
pretty good "Classic" as Agile books go.
I wonder if I'm the only person who was disappointed by this book? Apart
from the "aw, shucks--I'm just an idiot" tone, I didn't feel the examples
were well-chosen or well-presented. I also think it could have used a good
editor. There's one section where Kent explains something, then says it was
a bad example and that he should have talked about something else. A good
editor (or perhaps someone who wasn't in such awe of Kent) would have cut
that and just had him present the right example.

TDDBE a must-read, of course, but I really expected more from Kent Beck, the
single most important influence on me as a programmer.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Matt Secoske
2005-08-12 18:35:36 UTC
Permalink
Hi Mark
Post by Mark Wilden
Post by Brill Pappin
There is always Kent Becks "Test Driven Development: By Example". It's a
pretty good "Classic" as Agile books go.
I wonder if I'm the only person who was disappointed by this book? Apart
from the "aw, shucks--I'm just an idiot" tone, I didn't feel the examples
were well-chosen or well-presented. I also think it could have used a good
editor. There's one section where Kent explains something, then says it was
a bad example and that he should have talked about something else. A good
editor (or perhaps someone who wasn't in such awe of Kent) would have cut
that and just had him present the right example.
TDDBE a must-read, of course, but I really expected more from Kent Beck, the
single most important influence on me as a programmer.
I just finished it, and echo your remarks, except for the influence part...
I still can't get over the Pragmatic Programmers for that.

I felt that it could have used a couple of smaller examples at the beginning
to really get the TDD feel. I had already started doing some small TDD code
before I read the book, and must say that I learned more from that then the
book itself.

Anyway, my 2 cents.
--
Matt Secoske
http://www.secosoft.net


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-12 19:10:42 UTC
Permalink
Yah, you do have a point, but I thought it was fairly good for getting
the idea across... personally I had it pounded into me by my Mentor(s)
and checked out the book later... no substitute for practice.

I assume all those wanting practice with TDD have completed the
Test-First Challenge?
http://xp123.com/xplor/xp0201/

- Brill Pappin
Post by Mark Wilden
Post by Brill Pappin
There is always Kent Becks "Test Driven Development: By Example". It's a
pretty good "Classic" as Agile books go.
I wonder if I'm the only person who was disappointed by this book? Apart
from the "aw, shucks--I'm just an idiot" tone, I didn't feel the examples
were well-chosen or well-presented. I also think it could have used a good
editor. There's one section where Kent explains something, then says it was
a bad example and that he should have talked about something else. A good
editor (or perhaps someone who wasn't in such awe of Kent) would have cut
that and just had him present the right example.
TDDBE a must-read, of course, but I really expected more from Kent Beck, the
single most important influence on me as a programmer.
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-14 02:50:50 UTC
Permalink
Bill Wake's Test First Challenge is a great way to practice TDD without
actually having to figure out how to write good tests at the same time.
There are several people who have posted their solutions for comparison.
I'd highly recommend avoiding reading the code ahead of time for two
reasons. First, it doesn't mean much if you don't come up with the
solutions yourself. Second, I found the solutions to be horrible
examples of code produced by TDD. There obviously wasn't much
refactoring going on. Very obvious code smells like long methods and
switch statements simply weren't addressed in the solutions I have seen
to date. Maybe I'm just being too critical. But I wonder if anyone else
has felt the same?

Jim Cakalic
Post by Brill Pappin
Yah, you do have a point, but I thought it was fairly good for getting
the idea across... personally I had it pounded into me by my Mentor(s)
and checked out the book later... no substitute for practice.
I assume all those wanting practice with TDD have completed the
Test-First Challenge?
http://xp123.com/xplor/xp0201/
- Brill Pappin
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-14 21:53:04 UTC
Permalink
Oh, I absolutely agree; *do not* copy some the completed challenge...
the whole point to to get a feel for how it should work... it will *not*
help you write good agile code... but if you use the practices, it'll
make it easier to do the challenge.

- Brill Pappin
Post by Jim Cakalic
Bill Wake's Test First Challenge is a great way to practice TDD without
actually having to figure out how to write good tests at the same time.
There are several people who have posted their solutions for comparison.
I'd highly recommend avoiding reading the code ahead of time for two
reasons. First, it doesn't mean much if you don't come up with the
solutions yourself. Second, I found the solutions to be horrible
examples of code produced by TDD. There obviously wasn't much
refactoring going on. Very obvious code smells like long methods and
switch statements simply weren't addressed in the solutions I have seen
to date. Maybe I'm just being too critical. But I wonder if anyone else
has felt the same?
Jim Cakalic
Post by Brill Pappin
Yah, you do have a point, but I thought it was fairly good for getting
the idea across... personally I had it pounded into me by my Mentor(s)
and checked out the book later... no substitute for practice.
I assume all those wanting practice with TDD have completed the
Test-First Challenge?
http://xp123.com/xplor/xp0201/
- Brill Pappin
[Non-text portions of this message have been removed]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kay A. Pentecost
2005-08-13 21:51:10 UTC
Permalink
Hi, Mark,
-----Original Message-----
Sent: Friday, August 12, 2005 2:25 PM
Subject: Re: [XP] Re: How to unit test
Post by Brill Pappin
There is always Kent Becks "Test Driven Development: By
Example". It's a
Post by Brill Pappin
pretty good "Classic" as Agile books go.
I wonder if I'm the only person who was disappointed by this
book?
I thought the book was excellent, and I got started doing TDD with it, but I
was unable to get some of the exercises to work, and gave up on the book. I
was not a java programmer at the time.

Dave Astel's book Test-Driven Development: A Practical Guide, (
http://www.amazon.com/exec/obidos/tg/detail/-/0131016490/qid=1123969668/sr=1
-3/ref=sr_1_3/103-3896569-0190225?v=glance&s=books )was very easy to use,
had examples in several languages, (I wrote the chapter on VB6 <grin>) and
won a Jolt award.

You might check that out.

Also, Ron Jeffries's book, Extreme Programming Adventures in C# helps you
learn how Ron thinks as he's programming...
http://www.amazon.com/exec/obidos/tg/detail/-/0735619492/qid=1123969740/sr=1
-2/ref=sr_1_2/103-3896569-0190225?v=glance&s=books

I highly recommend both books.

Kay Pentecost




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Mark Wilden
2005-08-13 23:00:21 UTC
Permalink
Post by Kay A. Pentecost
Also, Ron Jeffries's book, Extreme Programming Adventures in C# helps you
learn how Ron thinks as he's programming...
http://www.amazon.com/exec/obidos/tg/detail/-/0735619492/qid=1123969740/sr=1
-2/ref=sr_1_2/103-3896569-0190225?v=glance&s=books
I just bought it about a half hour ago. :)



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-14 03:34:54 UTC
Permalink
Post by Brill Pappin
[...]
Post by Tunca Bergmen
As I said before, I am very new to these practices. One thing I
wonder about the philosophy of XP is, when we say the term "test
driven development", do we mean that we should change our
programming logic in order to make our testing logic simpler, even
when it has negative effects on the programming logic?
The sort answer is yes, change your "programming logic" but don't do it
*just* so you can test. If you do the simplest thing possible in your
code, your test should also be simple and it follows that if you make
the test simple, you code should follow suit (only doing exactly what is
required to pass the tests).
Actually (I can't stress enough) writing the test doesn't have negative
effects on the actual code under test (or shouldn't if your being good
about how you write your tests)... I can't name one single case where I
wouldn't want the test in place... but I can give you a multitude where
not writing the tests has a negative effect.
That said, it does mean you have very *different* code that what you
would have written had you not used TDD and I find that a lot of folks
new to TDD think of those differences as negative.
There are a whole slew of theories and practices that work with TDD
about why that new code structure is actually better, but I don't think
I could sum it all up in a single message or even sell you on the fact
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html
IMO - As a rule well written tests will guide you down the path to agile
code all by themselves and is the cornerstone of Agile development
practices.
- Brill Pappin
I went back and re-read Bill Caputo's blog entry and have to say that
overall, I agree. What concerns me, and I still struggle with this, is
how the community seems to consistently sidestep the issue of whether
Dependency Inversion is really being applied in the designs produced by
TDD. Bill says yes. But if I reconstruct what I think his pseudocode
says, his class looks like this:

public class CustomerDAO {
public void updateCustomer(Customer data) {
updateCustomerImpl(data, new RealDatabase("SomeSystem"));
}
// this method is for test purposes only
public void updateCustomerImpl(Customer data, IDatabase db) {
....
}
}

Frankly, I have problems with this on multiple levels. First, you've
introduced a method in the public API of the class that is only there
for testing. I mean, updateCustomerImpl it is only there for the test to
execute whereas the production code is expected to execute
updateCustomer. You might as well have named the method
"thisIsATestMethodForInjectingAMockDatabase" for god's sake. Nobody but
the test will use it. And as such I think you've violated one of Bill
Riel's heuristics of OOD that states you shouldn't clutter the public
API of a class with things that users of that class are not able to use
or are not interested in using.

Second, it is my opinion that this doesn't really decouple the
CustomerDAO from the RealDatabase. Yes, indeed, it provides a mechanism
for injecting a mock at test time. But I think what's really happened is
that we've decided to merely pay lip service to DIP. If it were
otherwise, shouldn't I be able to reuse CustomerDAO without dragging
along RealDatabase? But obviously I cannot. There is a compile time
dependency.

If I were to rewrite Robert Martin's copy program using this strategy it
would probably look something like this:

public class Copy {
// this method is for test purposes only
public void copy(Reader reader, Writer writer) {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
public void copy() {
copy(new KeyboardReader(), new PrinterWriter());
}
}

The copy method that takes a Reader and Writer, the real DIP
implementation, is essentially relegated to a test method. In scenarios
where I choose to put test classes in the same package as my production
classes, I'd probably even choose to make the method default access so
that only classes in the same package or subclasses could access it. Is
this really what we intend to recommend as good design?

Perhaps we would prefer a common alternative:

public class Copy {
public void copy() {
Reader reader = getReader();
Writer writer = getWriter();
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
// replace me if input does not come from keyboard
protected Reader getReader() {
return new KeyboardReader();
}
// replace me if output does not go to printer
protected Writer getWriter() {
return new PrinterWriter();
}
}

And then subclass Copy in our test and override (replace) the
implementation of getReader and getWriter to return mocks. Not a
particularly favorable alternative IMO. I think Jeff Langr calls this
pattern/idiom "deferred factory method mock".

Yet again we might do this:

public class Copy {
Reader reader;
Writer writer;
public Copy() {
this(new KeyboadReader(), new PrinterWriter());
}
// this constructor is for test purposes only
public Copy(Reader reader, Writer writer) {
this.reader = reader;
this.writer = writer;
}
public void copy() {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
}

Same as the first but with dependencies moved to a no-arg constructor.
Jeff Langr calls this "parameterized replacement mock". In this case the
language doesn't support it but the second constructor's intent is
revealed better by the name "CopyConstructorForTestPurposesOnly" because
we don't really intend that a client (other than the test) ever actually
use it. Again, in the right scenario I'd probably make it default access
so clients really /couldn't/ use it. No matter what, I guess I have to
add a comment telling everyone that this method is for test purposes
only? Does anybody else smell that?

So while I agree strongly that tests should influence the design of the
code, I'm left with a decidedly bad test in my mouth (odor in my nose)
when I then hear that the influence is to either add things to the
class's API that only the test is supposed to use or, conversely, add
things that only the production client(s) are supposed to use because
the design that emerged while writing the code test first was, well,
/too/ good?

Jim Cakalic


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
William E Caputo
2005-08-14 05:37:08 UTC
Permalink
Post by Jim Cakalic
Frankly, I have problems with this on multiple levels. First, you've
introduced a method in the public API of the class that is only there
for testing.
Hi Jim,

You raise some good arguments, and concerns. I started to respond with an
example -- and an explanation -- but then decided to go ahead and write
another article on the topic -- I've used this pattern a good bit in the
time since writing the first one, and was thinking of doing so anyway --
that describes a more sophisticated example (while adhering to the same
basic pattern). This one is based on several real code examples (the first
article examples -- while based on eariler experience -- were off-the-cuff
pseudo code written as I wrote the article). The downside of course is
that there is more code to wade through to see the pattern.

Here's the link: http://www.williamcaputo.com/archives/000225.html

I'll summarize my response to your concerns as: While the implementation
of the approach can take many forms -- some more appropriate to specific
circumstances than others -- the basic pattern holds. E.g. even in the
original article I mentioned that other forms of dependency injection
could be used as appropriate, and there are many ways to hide the
implementation from consumers of the class. In the new example, I chose an
approach that uses a constructor argument instead of an impl method -- the
"real" boundary access code class is assumed to be created by a higher
level driver object that accesses configuration information, and otherwise
creates the "real" objects for the sub system in question.

One thing though -- testability (and thus refactorability) is one of the
most important things I strive for in a design, so while I rarely find
that I create a method "just for testing" I would do so if my alternative
was code that was difficult to change, I can always hide the
method/interface in some way if necessary. That
"testability/refactorability" is a prime design goal is admitedly a
premise in both articles -- but then they are both describing a pattern
for applying TDD which is primarily a design technique for writing
testable, refactorable code, so...

Best,
Bill

William E. Caputo
http://www.williamcaputo.com
ThoughtWorks, Inc.
--------





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-14 17:27:08 UTC
Permalink
Hi, Bill.

So I read the new blog entry and I'd have to say on first blush, maybe I
read too fast, that the example completely does away with the offending
method/constructor that I was arguing against in my previous post. Your
original blog seemed to be saying, "It's all well and good to do this
dependency inversion thing for the test but good old fashioned tight
coupling is OK for the production code." Your new blog misses that
completely. Both test and client code use the class under test the same
way. Both are expected, by some means of no concern whatsoever to the
FooDomainObjectData class, to supply an implementation of IDatabase. I'm
perfectly happy with that. Where I would start to get heartburn again is
if I saw this show up:

public FooDomainObjectData() {
this(new RealDatabase());
}

as a constructor to be used by production code instead of the /real/
dependency inverting construtor that is now present.

Jim
Post by William E Caputo
Post by Jim Cakalic
Frankly, I have problems with this on multiple levels. First, you've
introduced a method in the public API of the class that is only there
for testing.
Hi Jim,
You raise some good arguments, and concerns. I started to respond with an
example -- and an explanation -- but then decided to go ahead and write
another article on the topic -- I've used this pattern a good bit in the
time since writing the first one, and was thinking of doing so anyway --
that describes a more sophisticated example (while adhering to the same
basic pattern). This one is based on several real code examples (the first
article examples -- while based on eariler experience -- were off-the-cuff
pseudo code written as I wrote the article). The downside of course is
that there is more code to wade through to see the pattern.
Here's the link: http://www.williamcaputo.com/archives/000225.html
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brian Slesinsky
2005-08-14 18:13:11 UTC
Permalink
Post by Jim Cakalic
Where I would start to get heartburn again is
public FooDomainObjectData() {
this(new RealDatabase());
}
as a constructor to be used by production code instead of the /real/
dependency inverting construtor that is now present.
It looks to me like you have a convenience constructor with no
arguments for a common case (used in production), and a more flexible
constructor with one argument (also used in production, indirectly).
The convenience constructor removes a bit of duplication if it's called
from more than one place. It seems like the only thing particularly
wrong with this is the idea that that the one-argument constructor is
"only for testing".

What will probably happen is that the zero-argument constructor will
get called from another class that also needs a mock database for
testing, in which case we'll inline it and move the dependency
injection up a level. But that's something we can learn as we go -
it's not something we need to think ahead about.

- Brian



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-14 18:22:04 UTC
Permalink
Post by Brian Slesinsky
Post by Jim Cakalic
Where I would start to get heartburn again is
public FooDomainObjectData() {
this(new RealDatabase());
}
as a constructor to be used by production code instead of the /real/
dependency inverting construtor that is now present.
It looks to me like you have a convenience constructor with no
arguments for a common case (used in production), and a more flexible
constructor with one argument (also used in production, indirectly).
The convenience constructor removes a bit of duplication if it's called
from more than one place. It seems like the only thing particularly
wrong with this is the idea that that the one-argument constructor is
"only for testing".
So are you saying the only choice I have is whether to accept
duplication or introduce coupling? The "convenience constructor"
introduces coupling. It does so to reduce duplication. From that I
derive that reducing duplication is more important than reducing
coupling ...


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brian Slesinsky
2005-08-14 09:17:29 UTC
Permalink
Post by Jim Cakalic
If I were to rewrite Robert Martin's copy program using this strategy it
public class Copy {
// this method is for test purposes only
public void copy(Reader reader, Writer writer) {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
public void copy() {
copy(new KeyboardReader(), new PrinterWriter());
}
}
The copy method that takes a Reader and Writer, the real DIP
implementation, is essentially relegated to a test method. In scenarios
where I choose to put test classes in the same package as my production
classes, I'd probably even choose to make the method default access so
that only classes in the same package or subclasses could access it. Is
this really what we intend to recommend as good design?
I think so. It looks to me like you've used "extract method" to
introduce a general-purpose stream-copy method that may come in handy
in other situations. That looks like good design to me. In fact, I've
written that very method in my last two projects and called it from
multiple places.

The comment is actually rather misleading. The method is called from
both test and production code, and if you ever need to copy a stream
somewhere else, you should use that method; it's not just for testing.

The test is really just checking that you can copy a stream correctly.
I'm not sure how you test the other part.

If nothing else is using it and it's not part of the intended
interface, I agree that it should be default access, However, I tend
to make it static and move it to a utility class so that I can find it
easily the next time I need it, in which case it's perfectly legitimate
to make it public.

- Brian



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-14 17:42:31 UTC
Permalink
Post by Brian Slesinsky
Post by Jim Cakalic
If I were to rewrite Robert Martin's copy program using this strategy it
public class Copy {
// this method is for test purposes only
public void copy(Reader reader, Writer writer) {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
public void copy() {
copy(new KeyboardReader(), new PrinterWriter());
}
}
The copy method that takes a Reader and Writer, the real DIP
implementation, is essentially relegated to a test method. In scenarios
where I choose to put test classes in the same package as my production
classes, I'd probably even choose to make the method default access so
that only classes in the same package or subclasses could access it. Is
this really what we intend to recommend as good design?
I think so. It looks to me like you've used "extract method" to
introduce a general-purpose stream-copy method that may come in handy
in other situations. That looks like good design to me. In fact, I've
written that very method in my last two projects and called it from
multiple places.
The comment is actually rather misleading. The method is called from
both test and production code, and if you ever need to copy a stream
somewhere else, you should use that method; it's not just for testing.
The test is really just checking that you can copy a stream correctly.
I'm not sure how you test the other part.
If nothing else is using it and it's not part of the intended
interface, I agree that it should be default access, However, I tend
to make it static and move it to a utility class so that I can find it
easily the next time I need it, in which case it's perfectly legitimate
to make it public.
- Brian
Hi, Brian.

This is exactly my point. Based on intent that I was reading from Bill's
original blog entry, the idea was that I introduced this dependency
inverting copy method /solely for the purpose of testing/. The comment
is not misleading but speaks loudly to the reason the method was
introduced in the first place. Using the line of reasoning from Bill's
blog, I concluded that it was too difficult in real life for anyone to
actually create Readers and Writers so in the production system all
calls would be to the no-arg copy method. Then I'd make it protected or
default so nobody could get access to it -- since it really is just for
test. And, Voila! No more nasty useless dependency inversion stuff
exposed to my clients. I don't think that's good design.

Nor do I think it appropriate that the Copy class is coupled to
KeyboardReader and PrinterWriter. So I agree with the last sentence of
your last paragraph. The Copy class ought to be kept pure, dependent
only on abstractions and not concretions. Relegate the coupling copy
method to being a client of the Copy class that always instantiates a
specific Reader and Writer. But don't keep it in the Copy class itself.

Jim


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-14 22:47:13 UTC
Permalink
Post by Brian Slesinsky
Post by Jim Cakalic
If I were to rewrite Robert Martin's copy program using this strategy it
[...]
Post by Brian Slesinsky
Post by Jim Cakalic
The copy method that takes a Reader and Writer, the real DIP
implementation, is essentially relegated to a test method. In scenarios
where I choose to put test classes in the same package as my production
classes, I'd probably even choose to make the method default access so
that only classes in the same package or subclasses could access it. Is
this really what we intend to recommend as good design?
I think so. It looks to me like you've used "extract method" to
introduce a general-purpose stream-copy method that may come in handy
in other situations. That looks like good design to me. In fact, I've
written that very method in my last two projects and called it from
multiple places.
Wouldn't you think of that as YAGNI?
When I hear "may come in handy" thats the first thing I think, although
that might not be what you meant.

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brian Slesinsky
2005-08-15 03:06:59 UTC
Permalink
Post by Brill Pappin
Post by Brian Slesinsky
I think so. It looks to me like you've used "extract method" to
introduce a general-purpose stream-copy method that may come in handy
in other situations. That looks like good design to me. In fact, I've
written that very method in my last two projects and called it from
multiple places.
Wouldn't you think of that as YAGNI?
When I hear "may come in handy" thats the first thing I think, although
that might not be what you meant.
Well, yes and no. The reason someone wrote the code in the first place
- okay, let's pretend I did - is because I actually do need to copy a
stream. The code was there but it was embedded in another method.
Then I extracted the method because I needed to test it, so that's
where the interface comes from. (Hmm... not very test-first, but
sometimes you don't know what test to write going in.) At that point I
might realize that all the method does is copy a stream and it's not
domain-specific at all, so I rename to something generic like
"copyStream".

As for where to put it, I'm okay with leaving such a method in the only
class that calls it under the YAGNI principle, but there's something to
be said for putting utility methods in a well-named utility class where
you can find them again, which I think of more as refactoring than as
adding unnecessary functionality.

- Brian



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-15 03:51:45 UTC
Permalink
Post by Brian Slesinsky
Post by Brill Pappin
Post by Brian Slesinsky
I think so. It looks to me like you've used "extract method" to
introduce a general-purpose stream-copy method that may come in handy
in other situations. That looks like good design to me. In fact, I've
written that very method in my last two projects and called it from
multiple places.
Wouldn't you think of that as YAGNI?
When I hear "may come in handy" thats the first thing I think, although
that might not be what you meant.
Well, yes and no. The reason someone wrote the code in the first place
- okay, let's pretend I did - is because I actually do need to copy a
stream. The code was there but it was embedded in another method.
Then I extracted the method because I needed to test it, so that's
where the interface comes from. (Hmm... not very test-first, but
sometimes you don't know what test to write going in.) At that point I
might realize that all the method does is copy a stream and it's not
domain-specific at all, so I rename to something generic like
"copyStream".
Ahh, I'd say that was a classic refactoring... I run into this situation
a lot when working with non-TDD code (people get upset when I call it
"legacy code") and it can sometimes be a real pain to extract something
like this depending on how coupled it was (seen some real WTFs there).

I could easily see separating it out into its own class as part of your
standard practice, as if you had done it with TDD in the first place...
nothing wrong with many small classes. I don't think I'd make it a
static utility (read global) class though... I'd simply keep it in the
package it was being used in until I had some reason to pull it up.

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-15 16:37:21 UTC
Permalink
Post by Brill Pappin
Post by Brian Slesinsky
Post by Brill Pappin
Post by Brian Slesinsky
I think so. It looks to me like you've used "extract method" to
introduce a general-purpose stream-copy method that may come in handy
in other situations. That looks like good design to me. In fact, I've
written that very method in my last two projects and called it from
multiple places.
Wouldn't you think of that as YAGNI?
When I hear "may come in handy" thats the first thing I think, although
that might not be what you meant.
Well, yes and no. The reason someone wrote the code in the first place
- okay, let's pretend I did - is because I actually do need to copy a
stream. The code was there but it was embedded in another method.
Then I extracted the method because I needed to test it, so that's
where the interface comes from. (Hmm... not very test-first, but
sometimes you don't know what test to write going in.) At that point I
might realize that all the method does is copy a stream and it's not
domain-specific at all, so I rename to something generic like
"copyStream".
Ahh, I'd say that was a classic refactoring... I run into this situation
a lot when working with non-TDD code (people get upset when I call it
"legacy code") and it can sometimes be a real pain to extract something
like this depending on how coupled it was (seen some real WTFs there).
I could easily see separating it out into its own class as part of your
standard practice, as if you had done it with TDD in the first place...
nothing wrong with many small classes. I don't think I'd make it a
static utility (read global) class though... I'd simply keep it in the
package it was being used in until I had some reason to pull it up.
- Brill Pappin
In the discussion prior to this we really weren't working with non-TDD
code. We were talking about a design that emerges through TDD
ultimately being subverted so it does not adhere to good OO design
principles because the resulting design was deemed too inconvenient to
use in practice. I'll circle back to my first statement that the good
dependency inverting method ends up being relegated to a test-only
method while the production code all calls something that tightly
couples the system by directly instantiating the concrete objects it
needs. In the end, the only place in the entire code base that uses
the DI copy method is the unit test. Had we not bothered to write unit
tests, we would never have wanted that method and likely would not
have written it. The fact that it does exist and might be useful one
day is nullified by all the example usage code in the system that
studiously avoids it.

Yes, you could move the method to some static utility class. That
doesn't fix the coupling problem. That only purifies the Copy class so
that it isn't the coupling point any more. Now the coupling point is
the CopyUtils class static copy method.

I know that it is a trivial example. I hope that it is not so trivial
that the point I am trying to make is too elusive.

I like what John Roth eluded to in a previous post when he several
times used words like configure and configuration. I believe that it
is possible to significantly loosen the coupling of a system by doing
exactly that -- externalizing the dependencies to a configuration.
Requests can then be made for objects which might otherwise be onerous
to initialize properly (or cause duplication) and the dependencies of
the resulting object are fulfilled by the ServiceLocator / Registry /
Dependency Injection Container that uses the configuration.

Jim




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-16 01:40:52 UTC
Permalink
Jim Cakalic wrote:
[...]
Post by Jim Cakalic
I like what John Roth eluded to in a previous post when he several
times used words like configure and configuration. I believe that it
is possible to significantly loosen the coupling of a system by doing
exactly that -- externalizing the dependencies to a configuration.
Requests can then be made for objects which might otherwise be onerous
to initialize properly (or cause duplication) and the dependencies of
the resulting object are fulfilled by the ServiceLocator / Registry /
Dependency Injection Container that uses the configuration.
Ahh... I see why you like Spring then (I'm reading the list backwards).
As mentioned in my last post, I think "externalizing the dependencies to
a configuration" is a bad idea and have seen very hard to maintain
applications that do just that (some of the worst I've ever come across).

I do agree with you though on the need for decoupling your code but I
think you have to achieve a balance between the idea of decoupling and
the ability to easily understand and maintain the application.
If we accept the fact that making the code easy to read and refactor
makes it more agile, then using configuration must take second place.

For example, why would I add a class name to a configuration file (as
you often do with Spring) when that class will very likely never change?
Some would say "because I might want to change it" but if it does
change, I have to write a bunch of code to support it anyway; the only
thing I've gained by specifying it in the configuration is to add
another step I *could* miss when doing my refactoring.

So, I ask this again.
What does it get me and at what cost?

Decoupling is good, but I don't want jelly holding everything together.

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Standley
2005-08-16 02:29:19 UTC
Permalink
I built application assemblers for a couple largish systems. They do a
lot of "get configuration, call setter". They have dependencies all over
the system with the setters, but they live alone in a package just for
this purpose. The only "static" configurations are a few mocks for
testing; most of the rest are key-classname pairs to provision strategy
factories.

The factories keep user group references out of my core system so I can
add user groups without touching the core. My core projects in Eclipse
have no dependencies on user group projects. We enforced that rule from
day one because adding user groups is a major goal of the system life
cycle and "stable core" is a personal goal. Should that have been
refactored in only when the second group came along?
Post by Brill Pappin
[...]
Post by Jim Cakalic
I like what John Roth eluded to in a previous post when he several
times used words like configure and configuration. I believe that it
is possible to significantly loosen the coupling of a system by doing
exactly that -- externalizing the dependencies to a configuration.
Requests can then be made for objects which might otherwise be onerous
to initialize properly (or cause duplication) and the dependencies of
the resulting object are fulfilled by the ServiceLocator / Registry /
Dependency Injection Container that uses the configuration.
Ahh... I see why you like Spring then (I'm reading the list backwards).
As mentioned in my last post, I think "externalizing the dependencies to
a configuration" is a bad idea and have seen very hard to maintain
applications that do just that (some of the worst I've ever come across).
I do agree with you though on the need for decoupling your code but I
think you have to achieve a balance between the idea of decoupling and
the ability to easily understand and maintain the application.
If we accept the fact that making the code easy to read and refactor
makes it more agile, then using configuration must take second place.
For example, why would I add a class name to a configuration file (as
you often do with Spring) when that class will very likely never change?
Some would say "because I might want to change it" but if it does
change, I have to write a bunch of code to support it anyway; the only
thing I've gained by specifying it in the configuration is to add
another step I *could* miss when doing my refactoring.
So, I ask this again.
What does it get me and at what cost?
Decoupling is good, but I don't want jelly holding everything together.
- Brill Pappin
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
y***@jhrothjr.com
2005-08-14 14:34:56 UTC
Permalink
From: "Jim Cakalic"
<***@yahoogroups.at.jhrothjr.com>
To: "***@yahoogroups.com"
<***@yahoogroups.at.jhrothjr.com>
Sent: Saturday, August 13, 2005 9:34 PM
Subject: Re: [XP] Re: How to unit test
Post by Jim Cakalic
I went back and re-read Bill Caputo's blog entry and have to say that
overall, I agree. What concerns me, and I still struggle with this, is
how the community seems to consistently sidestep the issue of whether
Dependency Inversion is really being applied in the designs produced by
TDD. Bill says yes. But...
...

It's an interesting issue, and there are two rather different issues
embedded in it.

The first is that TDD doesn't produce anything. The developer produces
code, and the code will be based on the developer's experiance and her
understanding of the problem and the architectural motifs required to solve
it.

The second is that there is a real difference between toy problems
and real world problems in systems with 100 kloc and up. The root issue
here is configurability: in toy problems you usually don't have to worry
about configurability; in large systems you do, especially if you have to
test them. [grin]

There are a lot of techniques that people use to attain configurability,
including containers, mock objects, dependency injection, Aspect
Oriented Programming, and so forth. The list goes on and on and on.

On one side, these things look kind of silly in toy problems: why go
to all that trouble. Also, you don't easily see "solutions" that won't
scale, or where the cure is worse than the disease if you try to scale
them.

In a large system, conceptual integrity is a major concern, so you
pick an architectural motif, or a cluster of cooperating motifs, and
stick with it. For most individual objects it's overkill, but the entire
system fits together smoothly if you do.

So the short answer is that I don't expect to see consistent
application of configurability patterns in the kind of toy and
example problems that get published on web sites and blogs.
Even if the author has a great deal of experiance, toy problems
won't invoke the patterns that she would automatically apply to
real problems in large systems.

John Roth
Post by Jim Cakalic
Jim Cakalic
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2005-08-14 14:58:19 UTC
Permalink
Hi John,

Very good points here: some of your best work. I was going to remark
on this thread that I generally don't worry much about things like
DIP, and that I attribute it to the fact that I don't write programs
that need it, so probably don't have as great an appreciation for
the practice as I might if I had spent the last N years writing huge
C++ programs, where it really matters.

I like your notion that the architectural stuff doesn't show up in
small examples because it's not time for it there. It's kind of a
YAGNI thing.

All this calls out a need, though, for examples that show these
techniques (as Bill's example did), and that somehow help people get
past the objection that in such a small program, the technique seems
premature.

Thanks,

Ron Jeffries
www.XProgramming.com
You don't need to see my identification.
These aren't the ideas you're looking for. Move along.
Post by y***@jhrothjr.com
Post by Jim Cakalic
I went back and re-read Bill Caputo's blog entry and have to say that
overall, I agree. What concerns me, and I still struggle with this, is
how the community seems to consistently sidestep the issue of whether
Dependency Inversion is really being applied in the designs produced by
TDD. Bill says yes. But...
...
It's an interesting issue, and there are two rather different issues
embedded in it.
The first is that TDD doesn't produce anything. The developer produces
code, and the code will be based on the developer's experiance and her
understanding of the problem and the architectural motifs required to solve
it.
The second is that there is a real difference between toy problems
and real world problems in systems with 100 kloc and up. The root issue
here is configurability: in toy problems you usually don't have to worry
about configurability; in large systems you do, especially if you have to
test them. [grin]
There are a lot of techniques that people use to attain configurability,
including containers, mock objects, dependency injection, Aspect
Oriented Programming, and so forth. The list goes on and on and on.
On one side, these things look kind of silly in toy problems: why go
to all that trouble. Also, you don't easily see "solutions" that won't
scale, or where the cure is worse than the disease if you try to scale
them.
In a large system, conceptual integrity is a major concern, so you
pick an architectural motif, or a cluster of cooperating motifs, and
stick with it. For most individual objects it's overkill, but the entire
system fits together smoothly if you do.
So the short answer is that I don't expect to see consistent
application of configurability patterns in the kind of toy and
example problems that get published on web sites and blogs.
Even if the author has a great deal of experiance, toy problems
won't invoke the patterns that she would automatically apply to
real problems in large systems.
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-14 18:18:01 UTC
Permalink
Post by y***@jhrothjr.com
From: "Jim Cakalic"
Post by Jim Cakalic
I went back and re-read Bill Caputo's blog entry and have to say that
overall, I agree. What concerns me, and I still struggle with this, is
how the community seems to consistently sidestep the issue of whether
Dependency Inversion is really being applied in the designs produced by
TDD. Bill says yes. But...
So the short answer is that I don't expect to see consistent
application of configurability patterns in the kind of toy and
example problems that get published on web sites and blogs.
Even if the author has a great deal of experiance, toy problems
won't invoke the patterns that she would automatically apply to
real problems in large systems.
John Roth
That's true, John, but not particularly encouraging. The less
experienced or well-read developer sees the toy and example problems,
looks at the derived solutions, and thinks that is all there is to it.
They go merrily on their way thinking they know how to practice DPP,
applying design principles and patterns, and end up constructing
horribly coupled systems. What's worse, they'll defend it to the grave
because they think they've done the right thing. After all, the code in
their system looks just like all the example code on discussion forums
and blogs posted by people who have experience in these matters. How
could it possibly be wrong?

What I think I hear you saying, though, and I like very much, is that
good object-oriented design principles should be adhered to when
designing and implementing -- not just classes but entire systems. The
same principles apply in the large as they do in the small. As problems
arise, which they always do, solutions should be harmonious with those
principles, not dissonant. This is important. And not a topic that I
have encountered frequently in my reading.

Regards,
Jim



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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
y***@jhrothjr.com
2005-08-14 19:00:02 UTC
Permalink
From: "Jim Cakalic"
<***@yahoogroups.at.jhrothjr.com>
To: "***@yahoogroups.com"
<***@yahoogroups.at.jhrothjr.com>
Sent: Sunday, August 14, 2005 12:18 PM
Subject: Re: [XP] Re: How to unit test
Post by Jim Cakalic
Post by y***@jhrothjr.com
From: "Jim Cakalic"
Post by Jim Cakalic
I went back and re-read Bill Caputo's blog entry and have to say that
overall, I agree. What concerns me, and I still struggle with this, is
how the community seems to consistently sidestep the issue of whether
Dependency Inversion is really being applied in the designs produced by
TDD. Bill says yes. But...
So the short answer is that I don't expect to see consistent
application of configurability patterns in the kind of toy and
example problems that get published on web sites and blogs.
Even if the author has a great deal of experiance, toy problems
won't invoke the patterns that she would automatically apply to
real problems in large systems.
John Roth
That's true, John, but not particularly encouraging. The less
experienced or well-read developer sees the toy and example problems,
looks at the derived solutions, and thinks that is all there is to it.
They go merrily on their way thinking they know how to practice DPP,
applying design principles and patterns, and end up constructing
horribly coupled systems. What's worse, they'll defend it to the grave
because they think they've done the right thing. After all, the code in
their system looks just like all the example code on discussion forums
and blogs posted by people who have experience in these matters. How
could it possibly be wrong?
Exactly. And that's not just a problem in this case, it's a problem
all over. A lot of the early textbooks on OO programming give
these neat inheritance diagrams with the geometry problem: a square
is-a rectangle, etc. Try to scale them up, or generalize them so that
they have to do something else and they fall apart. Real graphics
libraries don't do that.
Post by Jim Cakalic
What I think I hear you saying, though, and I like very much, is that
good object-oriented design principles should be adhered to when
designing and implementing -- not just classes but entire systems. The
same principles apply in the large as they do in the small. As problems
arise, which they always do, solutions should be harmonious with those
principles, not dissonant. This is important. And not a topic that I
have encountered frequently in my reading.
The larger you get, the more important coupling becomes as an
issue. Also, the more important being able to reconfigure the system
easily for testing, if for nothing else becomes as an issue.

To take another issue that comes up frequently: data bases. Do
you need them?

The usual advice we pass out is to start out without a data base.
This usually runs into the objection that since they're going to have
to have one eventually, they should start out with one. Then it gets
into a "we're older and wiser than you", "no, you're decrepit"
shoving match. This doesn't help.

I find it a bit more productive to point out that you're going to
run without a data base while developing: there is no other way
to run large numbers of tests in the short window available during
the TDD cycle. Then when you get the program to the point
where it needs one, you are _still_ going to be running without
one during the TDD cycle; the presence or absense of a data
base becomes a configuration option.

So the underlying question is: how to avoid painting ourselves
into a corner when it comes time to add the data base configuration
option? This leads to a (IMO) much more productive discussion
about whether the relentless removal of duplication will lead to
a design that can be easily configured.

John Roth
Post by Jim Cakalic
Regards,
Jim
[Non-text portions of this message have been removed]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Adrian Howard
2005-08-15 13:41:39 UTC
Permalink
On 14 Aug 2005, at 20:00, ***@jhrothjr.com wrote:
[snip]
Post by y***@jhrothjr.com
I find it a bit more productive to point out that you're going to
run without a data base while developing: there is no other way
to run large numbers of tests in the short window available during
the TDD cycle. Then when you get the program to the point
where it needs one, you are _still_ going to be running without
one during the TDD cycle; the presence or absense of a data
base becomes a configuration option.
[snip]

Very nice. I will fearlessly steal this piece of reasoning when next
I have to have this argument :-)

Ta,

Adrian



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-14 22:44:30 UTC
Permalink
That was a long article :) and some good points... I'll have to reread
it when I have my brain back from a weekend of sitting on the dock...

Let me say this now though... I'm *not* a fan of constructing dependent
objects in the code I'm working with, even if I provide a method of
doing so as well; many reasons for that but in this case it adds code
that I don't really need and can introduce bugs as other members of a
team refactor.

However you do strike on some good points and there are a few places
where DI breaks down. For instance, no matter how much you use that sort
of pattern, you will eventually come to an "end point" where all those
dependencies need to be constructed. There is no getting around it, but
with a little thought they can be in places that are obvious or
otherwise make sense.
It also means that you have to know exactly what the code is going...
there is no hocus-pocus "Magic Objects" that set up themselves... some
would think that was a bad thing, but personally I think it's better to
have to understand how it all works... and if your doing TDD you have a
test for the object that demonstrates how it's used (the whole test as
documentation thing).

Anyway, I'll re-read your article later when I am more receptive to the
ideas :) and make my observations then.

- Brill Pappin
[...]
Post by Jim Cakalic
Post by Brill Pappin
There are a whole slew of theories and practices that work with TDD
about why that new code structure is actually better, but I don't think
I could sum it all up in a single message or even sell you on the fact
(I'm just not that good a salesman). However I really like how this
fellow described it on his blog (sorry, can't find his name)
http://www.williamcaputo.com/archives/000019.html
IMO - As a rule well written tests will guide you down the path to agile
code all by themselves and is the cornerstone of Agile development
practices.
- Brill Pappin
I went back and re-read Bill Caputo's blog entry and have to say that
overall, I agree. What concerns me, and I still struggle with this, is
how the community seems to consistently sidestep the issue of whether
Dependency Inversion is really being applied in the designs produced by
TDD. Bill says yes. But if I reconstruct what I think his pseudocode
[...]
Post by Jim Cakalic
So while I agree strongly that tests should influence the design of the
code, I'm left with a decidedly bad test in my mouth (odor in my nose)
when I then hear that the influence is to either add things to the
class's API that only the test is supposed to use or, conversely, add
things that only the production client(s) are supposed to use because
the design that emerged while writing the code test first was, well,
/too/ good?
Jim Cakalic
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kent Beck
2005-08-16 23:02:48 UTC
Permalink
Jim,

I typically use a variant of your final example, but without the no-arg
constructor. People who want to create a Copy must supply a Reader and a
Writer. This removes the dependency on concrete Reader and Writer classes.

The first time I retrofitted this pattern I procrastinated for a week. I was
sure I was going to have to make a thousand changes and the effects would
ripple through the code. I ended up changing a handful of classes and a
double handful of methods, and the resulting code was clearer and cleaner
than the one with the implicit dependencies lurking in it.

Sincerely yours,

Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Saturday, August 13, 2005 8:35 PM
Subject: Re: [XP] Re: How to unit test
public class Copy {
Reader reader;
Writer writer;
public Copy() {
this(new KeyboadReader(), new PrinterWriter());
}
// this constructor is for test purposes only
public Copy(Reader reader, Writer writer) {
this.reader = reader;
this.writer = writer;
}
public void copy() {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
}
Same as the first but with dependencies moved to a no-arg
constructor.
Jeff Langr calls this "parameterized replacement mock". In
this case the
language doesn't support it but the second constructor's intent is
revealed better by the name
"CopyConstructorForTestPurposesOnly" because
we don't really intend that a client (other than the test)
ever actually
use it. Again, in the right scenario I'd probably make it
default access
so clients really /couldn't/ use it. No matter what, I guess
I have to
add a comment telling everyone that this method is for test purposes
only? Does anybody else smell that?
So while I agree strongly that tests should influence the
design of the
code, I'm left with a decidedly bad test in my mouth (odor in
my nose)
when I then hear that the influence is to either add things to the
class's API that only the test is supposed to use or, conversely, add
things that only the production client(s) are supposed to use because
the design that emerged while writing the code test first was, well,
/too/ good?
Jim Cakalic
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-17 00:01:52 UTC
Permalink
Yes, I thought that was a good way to do it, but I agree that the
zero-arg constructor should be left out. It's just a couple of extra
lines of code after all. I mention this because I wanted to express a
few examples from the trenches of why it's not always a good idea.

I've recently run across a situation where the test writer was using
JMock (cglib version) and it turns out that it actually creates an
instance of the class that it's mocking... naturally it uses the
zero-arg constructor to do it.

What was happening was that the test was passing when it should not
have, we could see why but it was not expected and we had to dig into
the test framework to find the culprit.

Another example from the same batch caused a chain reaction in the
constructor that looked for external resources... the result was that it
worked just fine in the dev environment but failed in a clean
environment that had never seen the code.

The moral of the story, keep your constructors simple; typically I use
them only for passing dependencies (particularly in an immutable object
situation). To me a constructor that takes params is an optimization
that will show up after refactoring.

- Brill Pappin
Post by Kent Beck
I typically use a variant of your final example, but without the no-arg
constructor. People who want to create a Copy must supply a Reader and a
Writer. This removes the dependency on concrete Reader and Writer classes.
[...]
Post by Kent Beck
Post by Jim Cakalic
public class Copy {
Reader reader;
Writer writer;
public Copy() {
this(new KeyboadReader(), new PrinterWriter());
}
// this constructor is for test purposes only
public Copy(Reader reader, Writer writer) {
this.reader = reader;
this.writer = writer;
}
public void copy() {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
}
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-17 01:04:24 UTC
Permalink
Kent,

Thanks for your input. I truly appreciate it. If I understand you
correctly, your Copy class would look like the snip you included below
minus the no-arg constructor.

Assuming that I understand you correctly, then I hope you can appreciate
that this is precisely what I've been advocating from the beginning of
my joining this thread. It is my thought that the presence of the no-arg
constructor is actually a subversion of our carefully crafted dependency
inverting design. We designed the class with a requirement that clients
supply the dependencies -- in this case a Reader and a Writer. But then
we undermined the design by adding the no-arg constructor thus
reintroducing the tight coupling to a concrete Reader and Writer.

So far, much to my chagrin, it seems you are the only person that has
agreed with this stance. My concern is I see this pattern occuring
(adding the no-arg constructor) frequently and even advocated by many as
the "right" way to design. I referenced Jeff Langrs experience report to
the 2004 Agile Development Conference. Were you there? Do you recall
what the reaction was?

Regards,
Jim
Post by Kent Beck
Jim,
I typically use a variant of your final example, but without the no-arg
constructor. People who want to create a Copy must supply a Reader and a
Writer. This removes the dependency on concrete Reader and Writer classes.
The first time I retrofitted this pattern I procrastinated for a week. I was
sure I was going to have to make a thousand changes and the effects would
ripple through the code. I ended up changing a handful of classes and a
double handful of methods, and the resulting code was clearer and cleaner
than the one with the implicit dependencies lurking in it.
Sincerely yours,
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Saturday, August 13, 2005 8:35 PM
Subject: Re: [XP] Re: How to unit test
public class Copy {
Reader reader;
Writer writer;
public Copy() {
this(new KeyboadReader(), new PrinterWriter());
}
// this constructor is for test purposes only
public Copy(Reader reader, Writer writer) {
this.reader = reader;
this.writer = writer;
}
public void copy() {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
}
Same as the first but with dependencies moved to a no-arg
constructor.
Jeff Langr calls this "parameterized replacement mock". In
this case the
language doesn't support it but the second constructor's intent is
revealed better by the name
"CopyConstructorForTestPurposesOnly" because
we don't really intend that a client (other than the test)
ever actually
use it. Again, in the right scenario I'd probably make it
default access
so clients really /couldn't/ use it. No matter what, I guess
I have to
add a comment telling everyone that this method is for test purposes
only? Does anybody else smell that?
So while I agree strongly that tests should influence the
design of the
code, I'm left with a decidedly bad test in my mouth (odor in
my nose)
when I then hear that the influence is to either add things to the
class's API that only the test is supposed to use or, conversely, add
things that only the production client(s) are supposed to use because
the design that emerged while writing the code test first was, well,
/too/ good?
Jim Cakalic
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brian Slesinsky
2005-08-17 03:14:57 UTC
Permalink
Post by Jim Cakalic
I hope you can appreciate
that this is precisely what I've been advocating from the beginning of
my joining this thread. It is my thought that the presence of the no-arg
constructor is actually a subversion of our carefully crafted
dependency
inverting design. We designed the class with a requirement that clients
supply the dependencies -- in this case a Reader and a Writer. But then
we undermined the design by adding the no-arg constructor thus
reintroducing the tight coupling to a concrete Reader and Writer.
Hi,

Now that I understand what you're advocating, I have a few questions.

Some background: I've mostly bought into dependency-injection as a way
to make code testable. However, I'm not rigorous about it and I don't
use any kind of standard container, and I'm wondering what the benefits
are, and what the general philosophy on configuration is.

In one project I worked on, many dependencies bubbled up to the main()
method for the system (which was a batch job). The main() method read
its configuration from a plain old property file. We were able to test
main() by supplying different property files in our end-to-end test
cases. A few of the properties were only there to make unit testing
easier (such as the host and port of a server that we would change to a
mock). We decided to make them "undocumented" properties that nobody
would use in production.

We were somewhat uncertain about how much configuration to export to
the configuration file. I'm generally of the opinion that we shouldn't
export too much because it would cause a combinatorial explosion of
possible configurations, most of which are irrelevant so there's no
point in testing them or exposing them so that someone could possibly
get them wrong in an environment where they don't have the safety net
provided by unit tests. In other words, many configuration parameters
should be changed only by editing the code, re-running the tests, and
shipping a new release.

So, let's see, I was going to ask a question...

I'm wondering how folks who use Spring or Pico treat the configuration
file that wires their application together? Is this something
sysadmins are supposed to understand and edit themselves, or is it
purely for the developers? And if it's only for developers, why do you
like XML better than Java?

- Brian



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Anthony Williams
2005-08-18 10:49:15 UTC
Permalink
Post by Jim Cakalic
It is my thought that the presence of the no-arg
constructor is actually a subversion of our carefully crafted dependency
inverting design. We designed the class with a requirement that clients
supply the dependencies -- in this case a Reader and a Writer. But then
we undermined the design by adding the no-arg constructor thus
reintroducing the tight coupling to a concrete Reader and Writer.
So far, much to my chagrin, it seems you are the only person that has
agreed with this stance.
I also agree with your stance; sorry for not coming forward sooner. A key
benefit of using dependency injection is to reduce the coupling, so adding a
no-arg constructor that couples the class to specific clients is rather
pointless. Instead, I prefer to have a simple factory class that constructs
the needed dependencies, and then constructs the class with the injected
dependencies. Rather than using the no-arg constructor, clients just use the
factory class instead.

Anthony
--
Anthony Williams
Software Developer



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-18 12:30:48 UTC
Permalink
Anthony,

That's what I've found to be most effective as well. Really, that is all
that the Spring BeanFactory does. It isn't such a complicated beast.

Regards,
Jim
Post by Anthony Williams
Post by Jim Cakalic
It is my thought that the presence of the no-arg
constructor is actually a subversion of our carefully crafted dependency
inverting design. We designed the class with a requirement that clients
supply the dependencies -- in this case a Reader and a Writer. But then
we undermined the design by adding the no-arg constructor thus
reintroducing the tight coupling to a concrete Reader and Writer.
So far, much to my chagrin, it seems you are the only person that has
agreed with this stance.
I also agree with your stance; sorry for not coming forward sooner. A key
benefit of using dependency injection is to reduce the coupling, so adding a
no-arg constructor that couples the class to specific clients is rather
pointless. Instead, I prefer to have a simple factory class that constructs
the needed dependencies, and then constructs the class with the injected
dependencies. Rather than using the no-arg constructor, clients just use the
factory class instead.
Anthony
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
William E Caputo
2005-08-19 00:49:51 UTC
Permalink
so adding a no-arg constructor that couples the class to specific clients
is rather
pointless.
(very busy this week, sorry for not being involved much)

I sorta get the feeling that I am -- perhaps because my blog entry was
cited early in the thread -- being lumped into the "not agreeing with
Jim's stance" category in this thread (instead of having no-position which
is closer to how I see it) So, I am going to summarize my stance:

1) I agree that I want to decouple my systems and that DI is one of my
favorite weapons to do so.
2) I am a pragmatist, and I will short circuit "Design purity" when I
reach TDD Simplicity and the code is working, easy to change, understand,
and add new features to.
3) Things are pointless only with regard to context -- as a general
statement I find it a subtle straw man argument (pointless in what
circumstance?)

4) The example from the original blog entry (written from memory) was
based on a real-world system: a multi-team large corporate framework whose
designers wanted to direct the instantion state -- i.e. they specficially
did *not* want that option configurable external to the development team.
Argue if it you like, but that was the desired requirement, it comes up a
lot in big IT, and the no arg ctor pattern provides a simple, easy to
change-if-you-change-your-mind solution that is still testable. Its in my
toolbox, you can put it there or not as you choose.

5) Software is interesting to me precisely because it does *not* succumb
to one-size-fits-all solutions -- that I have to weigh a variety of
tradoffs and tactical realities to accomplish larger strategic goals -- so
I don't have much interest in debating the context-free relative merits of
two approaches. I am neither agreeing nor disagreeing with Jim's stance --
I simply find such abstract design debates largely... well pointless. :-)

6) I want lots of approaches, because there are lots of contexts. The one
thing I find to be largely invariant is my desire to make my designs
testable. YMMV.

Best,
Bill

William E. Caputo
http://www.williamcaputo.com
ThoughtWorks, Inc.
--------





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Anthony Williams
2005-08-19 14:41:11 UTC
Permalink
Post by Anthony Williams
so adding a no-arg constructor that couples the class to specific clients
is rather
pointless.
I sorta get the feeling that I am -- perhaps because my blog entry was
cited early in the thread -- being lumped into the "not agreeing with
Jim's stance" category in this thread (instead of having no-position which
is closer to how I see it)
Sorry if you felt I was doing any "lumping" --- it wasn't my intention, I was
just explaining my stance.
Post by Anthony Williams
2) I am a pragmatist, and I will short circuit "Design purity" when I
reach TDD Simplicity and the code is working, easy to change, understand,
and add new features to.
Sounds sensible.
Post by Anthony Williams
3) Things are pointless only with regard to context -- as a general
statement I find it a subtle straw man argument (pointless in what
circumstance?)
You missed the first part of the sentence in your quote. Here it is in full:

" A key benefit of using dependency injection is to reduce the coupling, so
adding a no-arg constructor that couples the class to specific clients is
rather pointless."

If you're using DI to reduce coupling, you don't achieve that goal until you
remove the no-arg constructor.

OTOH, if you're purely using DI to enable testing, then leaving the no-arg
constructor in there costs nothing, except perhaps "design purity".
Post by Anthony Williams
4) The example from the original blog entry (written from memory) was
based on a real-world system: a multi-team large corporate framework whose
designers wanted to direct the instantion state -- i.e. they specficially
did *not* want that option configurable external to the development team.
Argue if it you like, but that was the desired requirement, it comes up a
lot in big IT, and the no arg ctor pattern provides a simple, easy to
change-if-you-change-your-mind solution that is still testable. Its in my
toolbox, you can put it there or not as you choose.
I can see why you might want it; I prefer to use a separate factory class, as
I said. How did you stop the configurable constructor being used outside the
development team?
Post by Anthony Williams
5) Software is interesting to me precisely because it does *not* succumb
to one-size-fits-all solutions -- that I have to weigh a variety of
tradoffs and tactical realities to accomplish larger strategic goals -- so
I don't have much interest in debating the context-free relative merits of
two approaches. I am neither agreeing nor disagreeing with Jim's stance --
I simply find such abstract design debates largely... well pointless. :-)
I'm happy with that. I find these debates tend to help me think out how I
might do things, and improve my toolbox. When I state an opinion, I usually
have a specific context in mind, though, even if not explicitly specified.
Post by Anthony Williams
6) I want lots of approaches, because there are lots of contexts. The one
thing I find to be largely invariant is my desire to make my designs
testable. YMMV.
Testable designs are always a good thing. I haven't found any circumstances
under which a more important goal would make a non-testable design *better*,
but sometimes the pragmatic solution is to stick with a non-testable design as
the effort required to change it is not worth the payoff.

Anthony
--
Anthony Williams
Software Developer



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kent Beck
2005-08-18 16:06:50 UTC
Permalink
Jim,

I'm a little surprised that you aren't getting more support. The technical
issue seems quite clear cut to me--for a small change in the API you get a
big improvement in the dependency structure. I was not at ADC 2004. What
happened at the presentation?

Sincerely yours,

Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Tuesday, August 16, 2005 6:04 PM
Subject: Re: [XP] Re: How to unit test
Kent,
Thanks for your input. I truly appreciate it. If I understand you
correctly, your Copy class would look like the snip you
included below
minus the no-arg constructor.
Assuming that I understand you correctly, then I hope you can
appreciate
that this is precisely what I've been advocating from the
beginning of
my joining this thread. It is my thought that the presence of
the no-arg
constructor is actually a subversion of our carefully crafted
dependency
inverting design. We designed the class with a requirement
that clients
supply the dependencies -- in this case a Reader and a
Writer. But then
we undermined the design by adding the no-arg constructor thus
reintroducing the tight coupling to a concrete Reader and Writer.
So far, much to my chagrin, it seems you are the only person that has
agreed with this stance. My concern is I see this pattern occuring
(adding the no-arg constructor) frequently and even advocated
by many as
the "right" way to design. I referenced Jeff Langrs
experience report to
the 2004 Agile Development Conference. Were you there? Do you recall
what the reaction was?
Regards,
Jim
Post by Kent Beck
Jim,
I typically use a variant of your final example, but without
the no-arg
Post by Kent Beck
constructor. People who want to create a Copy must supply a
Reader and a
Post by Kent Beck
Writer. This removes the dependency on concrete Reader and
Writer classes.
Post by Kent Beck
The first time I retrofitted this pattern I procrastinated
for a week. I was
Post by Kent Beck
sure I was going to have to make a thousand changes and the
effects would
Post by Kent Beck
ripple through the code. I ended up changing a handful of
classes and a
Post by Kent Beck
double handful of methods, and the resulting code was
clearer and cleaner
Post by Kent Beck
than the one with the implicit dependencies lurking in it.
Sincerely yours,
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Saturday, August 13, 2005 8:35 PM
Subject: Re: [XP] Re: How to unit test
public class Copy {
Reader reader;
Writer writer;
public Copy() {
this(new KeyboadReader(), new PrinterWriter());
}
// this constructor is for test purposes only
public Copy(Reader reader, Writer writer) {
this.reader = reader;
this.writer = writer;
}
public void copy() {
while ((int c = reader.read() != EOF) {
writer.write(c);
}
}
}
Same as the first but with dependencies moved to a no-arg
constructor.
Jeff Langr calls this "parameterized replacement mock". In
this case the
language doesn't support it but the second constructor's intent is
revealed better by the name
"CopyConstructorForTestPurposesOnly" because
we don't really intend that a client (other than the test)
ever actually
use it. Again, in the right scenario I'd probably make it
default access
so clients really /couldn't/ use it. No matter what, I guess
I have to
add a comment telling everyone that this method is for test
purposes
Post by Kent Beck
only? Does anybody else smell that?
So while I agree strongly that tests should influence the
design of the
code, I'm left with a decidedly bad test in my mouth (odor in
my nose)
when I then hear that the influence is to either add things to the
class's API that only the test is supposed to use or,
conversely, add
Post by Kent Beck
things that only the production client(s) are supposed to
use because
Post by Kent Beck
the design that emerged while writing the code test first
was, well,
Post by Kent Beck
/too/ good?
Jim Cakalic
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
[Non-text portions of this message have been removed]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-19 00:12:54 UTC
Permalink
Hi, Kent.

I thought as well that the issues were quite clear. But I've been
learning recently that many who say they practice TDD aren't getting the
intended benefit. I think this has to do with a focus on the testing
aspect of the activity and not the design aspect. One of the architects
at my current employer -- who invests in both training and mentoring for
TDD -- even went so far as to say that he thought it was perfectly OK
that developers thought of TDD as a testing activity. He thought they
would eventually catch on to the design aspect. But I don't see that
happening. Many stray back to test after and then to test never. There's
even an internal TDD forum on which I've been trying to engage other
developers on this topic. The silence has been deafening.

As for ADC 2004, Jeff responded earlier on the thread. He said:

The reaction to this message was twofold: a) most people were
nodding heads about the potential problems that using mocks can
introduce and b) the authors of the original mock paper suggested
that I was ignoring their primary intended use of mocks, which is to
explore design (I think the term has been broadened a bit from the
original intent, to their apparent dismay).

Regards,
Jim
Post by Kent Beck
Jim,
I'm a little surprised that you aren't getting more support. The technical
issue seems quite clear cut to me--for a small change in the API you get a
big improvement in the dependency structure. I was not at ADC 2004. What
happened at the presentation?
Sincerely yours,
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Tuesday, August 16, 2005 6:04 PM
Subject: Re: [XP] Re: How to unit test
Kent,
Thanks for your input. I truly appreciate it. If I understand you
correctly, your Copy class would look like the snip you
included below
minus the no-arg constructor.
Assuming that I understand you correctly, then I hope you can
appreciate
that this is precisely what I've been advocating from the
beginning of
my joining this thread. It is my thought that the presence of
the no-arg
constructor is actually a subversion of our carefully crafted
dependency
inverting design. We designed the class with a requirement
that clients
supply the dependencies -- in this case a Reader and a
Writer. But then
we undermined the design by adding the no-arg constructor thus
reintroducing the tight coupling to a concrete Reader and Writer.
So far, much to my chagrin, it seems you are the only person that has
agreed with this stance. My concern is I see this pattern occuring
(adding the no-arg constructor) frequently and even advocated
by many as
the "right" way to design. I referenced Jeff Langrs
experience report to
the 2004 Agile Development Conference. Were you there? Do you recall
what the reaction was?
Regards,
Jim
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2005-08-12 00:59:21 UTC
Permalink
Post by Tunca Bergmen
Post by Ron Jeffries
Would it be harmful to the application if you sorted the column
names in alphanumeric order?
This was the first thing that crossed my mind but I think sorting
columns provides no benefit for my algorithm except for making the
1. It would somehow decrease the performance.
I bet you can hardly measure how much ...
Post by Tunca Bergmen
2. It would complicate the algorithm.
I was supposing we might be using a language that knows how to sort
a list ... and in any case it should look about one message send
somewhere. I'd suggest looking at the actual code before deciding
how complex it is.
Post by Tunca Bergmen
As I said before, I am very new to these practices. One thing I
wonder about the philosophy of XP is, when we say the term "test
driven development", do we mean that we should change our
programming logic in order to make our testing logic simpler, even
when it has negative effects on the programming logic?
I don't see the conflict occurring at all often. This leaves me
confident that I should always make the code testable, which seems
always to leave it in a state where it's easy to make it both clear
and efficient.

Ron Jeffries
www.XProgramming.com
Think! -- Aretha Franklin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Tunca Bergmen
2005-08-12 10:24:54 UTC
Permalink
I sorted the columns and it solved my problem for now. I think as I
gain experience with TDD, solving such problems will be easier.
Post by Ron Jeffries
Post by Tunca Bergmen
1. It would somehow decrease the performance.
I bet you can hardly measure how much ...
You're right, it was insignificant.
Post by Ron Jeffries
Post by Tunca Bergmen
2. It would complicate the algorithm.
I was supposing we might be using a language that knows how to sort
a list ... and in any case it should look about one message send
somewhere. I'd suggest looking at the actual code before deciding
how complex it is.
You're right again. I used SortedList instead of Hashtable.

Thanks for your help.
Tunca




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-11 20:31:22 UTC
Permalink
I think maybe you need to break up your code a bit more and add simpler
tests for the sub parts, dilling down to the simplest level possible.

It sounds to me as if your not actually using TDD and wrote the code
first and the test second (or your dealing with a legacy system that has
no tests... no shortage of those).
I think you'll find that if you actually write the tests first, you
won't end up with problems like this, because at every step as you add
complexity, you know exactly what you going to get out of each chunk of
code.

- Brill Pappin
Post by Tunca Bergmen
Hi all,
First of all I want to introduce myself. I am a software developer from
Turkey. I am programming professionally since 1999. Currently, I mostly
develop in .NET using C#. I am very new to XP. I've just started applying
test first programming in one of my projects, using NUnit.
I am writing a simple OR mapper. I have a class that generates insert sql
according to metadata. First I wrote a test which knows the correct sql and
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates correct sql
string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?
Thanks,
Tunca Bergmen
[Non-text portions of this message have been removed]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Tunca Bergmen
2005-08-12 10:44:59 UTC
Permalink
Post by Brill Pappin
It sounds to me as if your not actually using TDD and wrote the code
first and the test second (or your dealing with a legacy system that has
no tests... no shortage of those).
I think you'll find that if you actually write the tests first, you
won't end up with problems like this, because at every step as you add
complexity, you know exactly what you going to get out of each
chunk of
Post by Brill Pappin
code.
Actually I wrote the test first, but now I realize that I made it
wrong way. I'm not dealing with a legacy system either. I wrote an
OR mapper about 3 years ago, and it served me well for a long time.
But now I want to extend my old, tired component, and I decided to
start from scratch. This would be a good practice for me in the way
of adapting to XP. I am currently on a vacation, and I do program
for 2-3 hours a day just to try new practices. Currently it goes
well, I learned some very useful stuff.





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Joe Da Silva
2005-08-12 14:52:44 UTC
Permalink
Post by Tunca Bergmen
I am currently on a vacation, and I do program
for 2-3 hours a day just to try new practices
If you want a Virtual Pair I can fit you in. Either I work on your
projects or you work on mine ("just to try new practices").
(I use gotomypc/gotomeeting)... joe @ joemagicdeveloper . com





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Loll, Michael F
2005-08-15 16:51:23 UTC
Permalink
Post by Jim Cakalic
I like what John Roth eluded to in a previous post when he several
times used words like configure and configuration. I believe that
it is possible to significantly loosen the coupling of a system by
doing exactly that -- externalizing the dependencies to a
configuration.
Post by Jim Cakalic
Requests can then be made for objects which might otherwise be onerous
to initialize properly (or cause duplication) and the dependencies of
the resulting object are fulfilled by the ServiceLocator / Registry /
Dependency Injection Container that uses the configuration.
I'm new to the whole IoC/DI world, but this sounds like what the Spring
framework does (amongst others). Is this what you are writing about?
Wiring up programs via some sort of configuration?


--Mike

The opinions expressed are my own and do not represent the official or
unofficial opinion or policy of the U.S. Department of State.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Hugo Garcia
2005-08-15 17:44:28 UTC
Permalink
You: Ok... so let's write the test.
Partner: Test? How about we just code it... i know how to do it.
You: Well... the problem is that my mom dropped me one too many times
and I can't code without doing a test.

--

Yeah I'm from NYC :P


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2005-08-15 21:00:14 UTC
Permalink
Post by Hugo Garcia
You: Ok... so let's write the test.
Partner: Test? How about we just code it... i know how to do it.
You: Well... the problem is that my mom dropped me one too many times
and I can't code without doing a test.
Yeah.

TDD works _great_ for a blue-sky project implementing your own logic.
It absolutely sucks when you know what legacy code to invoke, but
don't know how to query that legacy code for the effect.

Partner: But we already know how to Set the variable we want into that
GUI/database/whatever. Why do we have to research how to Get that
stinkin' variable back, just to prove we Set it??

Boss: What are you two up to?

Partner: It was Hugo's idea, boss! He's insisting on these stupid
tests again, and wasting 2 programmers' days on just one test!

Boss: Hugo, would you step into my office for a minute? And close the
door behind you.
--
Phlip
http://flea.sourceforge.net/resume.html


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Russell Gold
2005-08-15 23:53:44 UTC
Permalink
Post by Phlip
Post by Hugo Garcia
You: Ok... so let's write the test.
Partner: Test? How about we just code it... i know how to do it.
You: Well... the problem is that my mom dropped me one too many times
and I can't code without doing a test.
Yeah.
TDD works _great_ for a blue-sky project implementing your own logic.
It absolutely sucks when you know what legacy code to invoke, but
don't know how to query that legacy code for the effect.
Which is why you have to refactor your legacy code first... TDD only
becomes possible once you have a bit of an opening in which to work.
Much of my time is spent getting ready to do TDD.

And so far, my bosses have been ecstatic with the result.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Doug South
2005-08-16 01:27:59 UTC
Permalink
Post by Russell Gold
Which is why you have to refactor your legacy code first... TDD only
becomes possible once you have a bit of an opening in which to work.
Much of my time is spent getting ready to do TDD.
Agreed, but refactoring with the unit tests isn't fun. It is the first
step in the right direction, but the payoff feels so far away right
now. I'm in the process of abstracting out data and business into
their own layers to give us a fighting chance to do some reall TDD. It
is big and it is boring and it is important. <sigh> 8)
Post by Russell Gold
And so far, my bosses have been ecstatic with the result.
At least we are getting some active support from the boss...

Regards,
Doug
--
blog = http://www.trontos.com/dsouth/blog/

Any sufficiently complicated Java program requires a programmable IDE
to make up for the half of Common Lisp not implemented in the program
itself.
-- Peter Seibel


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Russell Gold
2005-08-16 02:46:11 UTC
Permalink
Post by Doug South
Post by Russell Gold
Which is why you have to refactor your legacy code first... TDD only
becomes possible once you have a bit of an opening in which to work.
Much of my time is spent getting ready to do TDD.
Agreed, but refactoring with the unit tests isn't fun. It is the first
step in the right direction, but the payoff feels so far away right
now. I'm in the process of abstracting out data and business into
their own layers to give us a fighting chance to do some reall TDD. It
is big and it is boring and it is important. <sigh> 8)
I wonder if you are trying to do too much refactoring up front. I
usually find that I can make progress with a specific change after
just a little bit of refactoring - enough to let me write a few tests.
Then I can often make the change I need. I will come back and refactor
some more only when I need to make more changes and want tests to
guide or protect me. Don't make the perfect the enemy of the good.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Doug South
2005-08-16 03:05:17 UTC
Permalink
Post by Russell Gold
I wonder if you are trying to do too much refactoring up front. I
usually find that I can make progress with a specific change after
just a little bit of refactoring - enough to let me write a few tests.
Then I can often make the change I need. I will come back and refactor
some more only when I need to make more changes and want tests to
guide or protect me. Don't make the perfect the enemy of the good.
Well, we aren't XP'ing just yet. We mostly have a go ahead to do so,
but we are really waiting to get an experienced Coach on site for a
few days before we dive head first into it (hopefully in the next 1-2
weeks). I was hired to do the refactoring. I've simplified it greatly
from what I initially was hoping to do. Very simple refactoring.
There's just an awful lot of it to be done, even in its simple form. I
probably am missing something, but from my knowledge and experience,
I've refactored the task into the smallest atomic thing I could come
up with and it is still a bit big. I keep looking for an out, but part
of the problem is that when I've found an out, some of the old stuff
I've done then because an issue. The main problem is that I'm working
with about 3-4 years of legacy code.

Anyway, I should probably be focused on the refactoring right now... 8)

Regards,
Doug
--
blog = http://www.trontos.com/dsouth/blog/

Any sufficiently complicated Java program requires a programmable IDE
to make up for the half of Common Lisp not implemented in the program
itself.
-- Peter Seibel


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Hugo Garcia
2005-08-16 19:57:22 UTC
Permalink
So, what you guys are saying is to refactor without unit test so that
the code can be tested and once you have refactored enough so that
there are places in the refactored code where you can hook basic tests
then do TDD to finish the big refactoring of that part of the code you
are working on?

-H


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim McMaster
2005-08-16 20:12:24 UTC
Permalink
Post by Hugo Garcia
So, what you guys are saying is to refactor without unit test so that
the code can be tested and once you have refactored enough so that
there are places in the refactored code where you can hook basic tests
then do TDD to finish the big refactoring of that part of the code you
are working on?
This is the approach suggested by Michael Feathers in his book, "Working
Effectively With Legacy Code". He shows a lot of small dependency-breaking
refactorings that enable getting the code under test. Then you can get to
the real refactoring.

I highly recommend this book. Feathers did an excellent job.
--
Jim McMaster
mailto:***@comcast.net




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-16 23:46:50 UTC
Permalink
Post by Hugo Garcia
So, what you guys are saying is to refactor without unit test so that
the code can be tested and once you have refactored enough so that
there are places in the refactored code where you can hook basic tests
then do TDD to finish the big refactoring of that part of the code you
are working on?
Actually, I'd say you should be adding your tests as you go along
refactoring... sometime it will be difficult, but well worth the effort.

Fixing this situation often entails rewriting code which is more likely
to be the case, so add your tests for all that new code you create.

After a while your confidence will go up in the code you have
refactored/rewritten, and the tests will also help with the rest of the
system by telling you if you have broken something.


- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brandon Campbell
2005-08-17 13:50:07 UTC
Permalink
This is the approach suggested by Michael Feathers in his book, "Working
Effectively With Legacy Code". He shows a lot of small dependency-breaking
refactorings that enable getting the code under test. Then you can get to
the real refactoring.
I highly recommend this book. Feathers did an excellent job.
I second this recommendation, this book is a must read for anyone working
with legacy code and attempting to get that code under unit test.

--
Jim McMaster
--
Brandon Campbell


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-15 18:26:48 UTC
Permalink
Post by Jim Cakalic
Post by Jim Cakalic
I like what John Roth eluded to in a previous post when he several
times used words like configure and configuration. I believe that
it is possible to significantly loosen the coupling of a system by
doing exactly that -- externalizing the dependencies to a
configuration.
Post by Jim Cakalic
Requests can then be made for objects which might otherwise be onerous
to initialize properly (or cause duplication) and the dependencies of
the resulting object are fulfilled by the ServiceLocator / Registry /
Dependency Injection Container that uses the configuration.
I'm new to the whole IoC/DI world, but this sounds like what the Spring
framework does (amongst others). Is this what you are writing about?
Wiring up programs via some sort of configuration?
--Mike
Yes. Spring, PicoContainer, and HiveMind are all instances of an
IoC/DI container that can wire objects together by configuration.

Jim




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-15 18:47:10 UTC
Permalink
I don't know if "wire objects together by configuration" is really a
marker for DI or even a good thing for an agile developer to be doing...
personally I avoid Spring for the very fact that it's all done at a
meta-data level and you haven't really injected anything except to write
some meta-code to "glue" the components together (to clarify, Glue is
good but doing it in XML is bad).

As others and myself have written before, "All I wanted was a Pepsi".

MO of course.
- Brill Pappin
Post by Jim Cakalic
Post by Jim Cakalic
Post by Jim Cakalic
I like what John Roth eluded to in a previous post when he several
times used words like configure and configuration. I believe that
it is possible to significantly loosen the coupling of a system by
doing exactly that -- externalizing the dependencies to a
configuration.
Post by Jim Cakalic
Requests can then be made for objects which might otherwise be onerous
to initialize properly (or cause duplication) and the dependencies of
the resulting object are fulfilled by the ServiceLocator / Registry /
Dependency Injection Container that uses the configuration.
I'm new to the whole IoC/DI world, but this sounds like what the Spring
framework does (amongst others). Is this what you are writing about?
Wiring up programs via some sort of configuration?
--Mike
Yes. Spring, PicoContainer, and HiveMind are all instances of an
IoC/DI container that can wire objects together by configuration.
Jim
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-15 21:21:26 UTC
Permalink
Post by Brill Pappin
I don't know if "wire objects together by configuration" is really a
marker for DI or even a good thing for an agile developer to be doing...
personally I avoid Spring for the very fact that it's all done at a
meta-data level and you haven't really injected anything except to write
some meta-code to "glue" the components together (to clarify, Glue is
good but doing it in XML is bad).
As others and myself have written before, "All I wanted was a Pepsi".
MO of course.
- Brill Pappin
I'm not sure why you think that. As Martin Fowler pointed out in his
article on IoC and Dependency Injection, the choice is really between
locator and injector. Both have their pros and cons. Fowler evidently
prefers locator because it is comfortable and easy for him to
understand. Those who have been working with injector for awhile can't
figure out what all the fuss is about.

Jim









To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
y***@jhrothjr.com
2005-08-15 22:19:33 UTC
Permalink
From: "Jim Cakalic"
<***@yahoogroups.at.jhrothjr.com>
To: "***@yahoogroups.com"
<***@yahoogroups.at.jhrothjr.com>
Sent: Monday, August 15, 2005 3:21 PM
Subject: [XP] Re: How to unit test
Post by Jim Cakalic
Post by Brill Pappin
I don't know if "wire objects together by configuration" is really a
marker for DI or even a good thing for an agile developer to be doing...
personally I avoid Spring for the very fact that it's all done at a
meta-data level and you haven't really injected anything except to write
some meta-code to "glue" the components together (to clarify, Glue is
good but doing it in XML is bad).
As others and myself have written before, "All I wanted was a Pepsi".
MO of course.
- Brill Pappin
I'm not sure why you think that. As Martin Fowler pointed out in his
article on IoC and Dependency Injection, the choice is really between
locator and injector. Both have their pros and cons. Fowler evidently
prefers locator because it is comfortable and easy for him to
understand. Those who have been working with injector for awhile can't
figure out what all the fuss is about.
The trouble with most of these solutions is that they're kind of
special case. Service Locator works great if you're trying to
plug in a few services, for relatively modest values of few. It
doesn't work at all for testing where you want to plug in
mocks all over the place.

Spring blessedly doesn't try to solve the entire world for you,
but it still brings in things like AOP and XML configuration files
for the recommended small configuration. And it doesn't seem
to have a really lightweight solution to the testing problem we
are considering: how to plug in mocks, fakes and stubs on a
per test basis easily.

Picocontainer is a lot smaller, and given Java I suppose a
50k jar isn't all that unreasonable. However, it only deals
with constructor injection (Spring does both constructors
and setters) and still requires that all your managed objects
be registered, either programatically or via an external
XML file (nanocontainer). Mercifully though it does
support testing, including examples of JUnit and mocks.

I've occasionally been tempted to write a configuration
utility in Python that should be both smaller and more
dynamic. Unfortunately, I haven't had a real use for it
yet.

John Roth
Post by Jim Cakalic
Jim
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-16 13:54:49 UTC
Permalink
Post by y***@jhrothjr.com
The trouble with most of these solutions is that they're kind of
special case. Service Locator works great if you're trying to
plug in a few services, for relatively modest values of few. It
doesn't work at all for testing where you want to plug in
mocks all over the place.
Spring blessedly doesn't try to solve the entire world for you,
but it still brings in things like AOP and XML configuration files
for the recommended small configuration. And it doesn't seem
to have a really lightweight solution to the testing problem we
are considering: how to plug in mocks, fakes and stubs on a
per test basis easily.
Picocontainer is a lot smaller, and given Java I suppose a
50k jar isn't all that unreasonable. However, it only deals
with constructor injection (Spring does both constructors
and setters) and still requires that all your managed objects
be registered, either programatically or via an external
XML file (nanocontainer). Mercifully though it does
support testing, including examples of JUnit and mocks.
Hmm. I think the solution for testing is to completely ignore the
container. Simply construct the object with its dependencies in the
test. You can supply mocks for all the dependencies so you are really
testing the class in isolation. No container necessary. Since the class
was designed from the beginning so that its dependencies are supplied by
an external source you don't need to add anything to the public API to
make this happen.

It is a common misconception that Picocontainer does not support setter
injection. It supported only constructor injection for something like
the first two months of its life after which setter injection was added.
I think the disconnect is that the authors advocate constructor
injection. I tend to like it better myself.

Somewhere along the way, when you have objects with dependencies, you
are going to need to do something to supply those dependencies. Some
people seem to be more comfortable with a "pull" model and have
components acquire those dependencies by direct coupling. Others prefer
a "push" model and so choose to manage their dependencies through
configuration of a factory / container. I tend to think the pull model
works fine up to a point after which I would prefer to use the push
model. I think dependency injection containers help significantly in
designing larger systems that are loosely coupled, in part because they
encourage designing components that do not couple themselves in code.

Excessive use of XML is a bad thing. So is aversion to it.

Jim


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



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-16 01:18:15 UTC
Permalink
Post by Jim Cakalic
Post by Brill Pappin
I don't know if "wire objects together by configuration" is really a
marker for DI or even a good thing for an agile developer to be doing...
personally I avoid Spring for the very fact that it's all done at a
meta-data level and you haven't really injected anything except to write
some meta-code to "glue" the components together (to clarify, Glue is
good but doing it in XML is bad).
As others and myself have written before, "All I wanted was a Pepsi".
MO of course.
- Brill Pappin
I'm not sure why you think that. As Martin Fowler pointed out in his
article on IoC and Dependency Injection, the choice is really between
locator and injector. Both have their pros and cons. Fowler evidently
prefers locator because it is comfortable and easy for him to
understand. Those who have been working with injector for awhile can't
figure out what all the fuss is about.
IMO injecting concrete code from "meta-code" is an anti pattern in and
of itself.

I'm really only interested in doing the most simple and direct thing I
can and XML configuration is certainly not it.
I'd say Spring uses an injection pattern (which I like), but how you
inject is with long and complex XML files (which I don't like).

Creating configuration files for an application will eventually happen,
there are just some things that need it; however starting out using them
has a Smell all its own... I simply don't need the complexity and I'd
prefer my code to be much more concrete... When it all works, then I
*might* add configuration where it's warranted but nothing more.

Now, Spring looks like it could be used in a concrete way but the
developers don't promote it or document how you would use it, so why
should I bother when it's just forcing me to write "meta" code, messing
up my nice concrete application, causing me pain during testing (there
are several test smells that apply here) and refactoring/rewriting?

Now that I've ranted a bit on the subject, I actually find it
disappointing because I can see that the people working with Spring have
some very good ideas that I'd like to take advantage of, but the cost
simply seems to high.

Maybe I've missed the point of Spring or misjudged the cost and I should
ask the question of this list:
"What does it *actually* do for me and at what cost?"

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Rob Park
2005-08-16 17:28:07 UTC
Permalink
Not sure I agree that there is much real "cost" there... is it really much
cost if you can simply plug in a framework to handle the injection for you?
It's not anywhere near as invasive as say EJB... And personally, I find the
XML configuration easy to maintain and I'd rather have it there than an
equally long .properties file or perhaps hard coded.

So I guess my point is that I don't think you can include in the cost of
Spring, the coding that Rod and company have done. And since that's been
done for us, if you just use what you need, the cost is lower than rolling
your own mechanism.

.rob.
Subject: [XP] The cost of Spring Was: Re: How to unit test
Date: Mon, 15 Aug 2005 21:18:15 -0400
Maybe I've missed the point of Spring or misjudged the cost and I should
"What does it *actually* do for me and at what cost?"
- Brill Pappin
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-16 23:43:18 UTC
Permalink
Post by Rob Park
Not sure I agree that there is much real "cost" there... is it really much
cost if you can simply plug in a framework to handle the injection for you?
It's not anywhere near as invasive as say EJB... And personally, I find the
XML configuration easy to maintain and I'd rather have it there than an
equally long .properties file or perhaps hard coded.
First let me say that I agree with you, it's not nearly as bad as EJB.

However, "hard code" is exactly what I'd prefer as it does *exactly*
what I'm telling it to do... if I have to maintain an extra config files
(XML or key value pair) then I've added cost. Obscurity, testing with
external resources, forgetting to update the config... the list goes on.

Are frameworks good? Sure some are and some should make a quick trip
into history. AS for Spring, I've love to use the framework but not if I
have to maintain yet another XML configuration file.
Post by Rob Park
So I guess my point is that I don't think you can include in the cost of
Spring, the coding that Rod and company have done. And since that's been
done for us, if you just use what you need, the cost is lower than rolling
your own mechanism.
There most certainly is a cost, but I guess the value of the framework
must be weighed against that cost for each situation, however I have not
yet come across a situation that I *needed* Spring for, it has always
been faster to use TDD and implement exactly what I need and nothing more.

I think if the Spring folks want to get customers like myself, then they
will have to make sure it can be hard coded and document that fact/feature.

[...]
Post by Rob Park
Post by Brill Pappin
Maybe I've missed the point of Spring or misjudged the cost and I should
"What does it *actually* do for me and at what cost?"
So, I ask the question again: "What does it *actually* do for me and at
what cost?"

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Edmund Schweppe
2005-08-17 01:46:01 UTC
Permalink
Post by Rob Park
Not sure I agree that there is much real "cost" there... is it really
much cost if you can simply plug in a framework to handle the
injection for you?
That depends in large part on how much it costs for me (and my
teammates) to learn Yet Another Wonder Tool.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-17 03:30:52 UTC
Permalink
The statement was made previously that using tools like Spring and
meta-data expressed in XML was somehow something that no Agile developer
would do. (Sorry that I can't remember at the moment to whom I should
attribute that remark.) I was looking again at the /Principles behind
the Agile Manifesto/ page. I'm wondering which of the principles there
are intrinsically violated by Spring (DI containers in general) or XML
configurations. I'd refer to Simplicity (as described on that page) as a
principle that possibly supports leveraging the work of others ...

Jim
Post by Edmund Schweppe
Post by Rob Park
Not sure I agree that there is much real "cost" there... is it really
much cost if you can simply plug in a framework to handle the
injection for you?
That depends in large part on how much it costs for me (and my
teammates) to learn Yet Another Wonder Tool.
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
y***@jhrothjr.com
2005-08-17 04:04:25 UTC
Permalink
From: "Jim Cakalic"
<***@yahoogroups.at.jhrothjr.com>
To: "***@yahoogroups.com"
<***@yahoogroups.at.jhrothjr.com>
Sent: Tuesday, August 16, 2005 9:30 PM
Subject: Re: [XP] The cost of Spring Was: Re: How to unit test
Post by Jim Cakalic
The statement was made previously that using tools like Spring and
meta-data expressed in XML was somehow something that no Agile developer
would do. (Sorry that I can't remember at the moment to whom I should
attribute that remark.) I was looking again at the /Principles behind
the Agile Manifesto/ page. I'm wondering which of the principles there
are intrinsically violated by Spring (DI containers in general) or XML
configurations. I'd refer to Simplicity (as described on that page) as a
principle that possibly supports leveraging the work of others ...
OAOO (Once And Only Once) or DRY (don't repeat yourself.)
There should be exactly one place to look for the authoritative
answer to any question.

Unless you're very thorough about making _all_ of your objects
relate through the configuration file each and every time, you've
got two places to look whenever you want to figure out what's
coupled to what.

And even if you do, that file almost certainly depends on a lot
of unstated rules about what can be connected to what under
what circumstances.

You've mentioned this before as an objection to using containers
like Spring: you never know quite where to look for an answer
to what's hooked to what.

Simply moving to putting the configuration information into
Java doesn't automatically fix this either. It's something that
I don't have a great answer to, although I suspect that the
practice of always using domain specific objects for publicly
accessable values (conversely, never using standard language
objects for these values) might go a long way to making
connectability explicit (or at least easily derivable).

John Roth
Post by Jim Cakalic
Jim
Post by Edmund Schweppe
Post by Rob Park
Not sure I agree that there is much real "cost" there... is it really
much cost if you can simply plug in a framework to handle the
injection for you?
That depends in large part on how much it costs for me (and my
teammates) to learn Yet Another Wonder Tool.
[Non-text portions of this message have been removed]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-17 06:14:43 UTC
Permalink
I'm sorry, but that argument just doesn't hold water for me. It's like
saying that there should be one and only one way of getting a reference
to an object. Therefore, the only way one object can have reference to
another object is if it directly instantiates the object itself through
the new operator. No one is allowed to pass an object reference into a
method or constructor because that would be a different way of getting a
reference. And those pesky creational design patterns -- factories,
builders, prototypes, and especially singletions -- we'll have none that
mind you.

I don't recall ever presenting the objection to using Spring (or other
DI containers) that you attribute to me. If I did then I'm certainly
willing to admit when I'm wrong. :-)

As far as XP values go, what about Courage? Not to pick on him, but
after reading Jeff Langr's /Essential Java Style/ book, I recall reading
an article by him in Software Development Magazine in which he used the
example of "safety braces" as a lack of courage. If I have courage, he
contends, I don't need to use braces around a single line block of code
to prevent myself or someone else from making an error if they might
want to add a second line to the block. In that vein, I'm not afraid
that I can't learn to use what you call "the wonder tool". I'm not
afraid that it will be too obscure. I'm not afraid that I'll forget to
update the configuration. I'm not afraid that it will get out of hand
and "take over" the project. I'm not afraid that I won't be able to
determine when to use the tool and when not to use it. I can be
courageous because I have unit tests that allow me to test classes in
isolation from their dependencies -- I run these often because they are
fast. I can be courageous because I have integration tests that will
help me determine if I've broken the configuration -- I run these
frequently as I practice continuous integration. I can be courageous
because my pair partner is looking over my shoulder -- I know that
someone other than me understands what is going on.

Jim
Post by y***@jhrothjr.com
From: "Jim Cakalic"
Sent: Tuesday, August 16, 2005 9:30 PM
Subject: Re: [XP] The cost of Spring Was: Re: How to unit test
Post by Jim Cakalic
The statement was made previously that using tools like Spring and
meta-data expressed in XML was somehow something that no Agile developer
would do. (Sorry that I can't remember at the moment to whom I should
attribute that remark.) I was looking again at the /Principles behind
the Agile Manifesto/ page. I'm wondering which of the principles there
are intrinsically violated by Spring (DI containers in general) or XML
configurations. I'd refer to Simplicity (as described on that page) as a
principle that possibly supports leveraging the work of others ...
OAOO (Once And Only Once) or DRY (don't repeat yourself.)
There should be exactly one place to look for the authoritative
answer to any question.
Unless you're very thorough about making _all_ of your objects
relate through the configuration file each and every time, you've
got two places to look whenever you want to figure out what's
coupled to what.
And even if you do, that file almost certainly depends on a lot
of unstated rules about what can be connected to what under
what circumstances.
You've mentioned this before as an objection to using containers
like Spring: you never know quite where to look for an answer
to what's hooked to what.
Simply moving to putting the configuration information into
Java doesn't automatically fix this either. It's something that
I don't have a great answer to, although I suspect that the
practice of always using domain specific objects for publicly
accessable values (conversely, never using standard language
objects for these values) might go a long way to making
connectability explicit (or at least easily derivable).
John Roth
[Non-text portions of this message have been removed]



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-17 17:39:49 UTC
Permalink
Just to set the record sideways.

I (Brill) am mostly against Spring and Jim is mostly for Spring (as far
as I can tell).

The discussion is really about the use of Meta-data as a "glue", the
extent of it in frameworks like Spring and how that translates to the
principals of "agility".

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-18 02:34:56 UTC
Permalink
Brill,

I disagree in that I am not "mostly for Spring". I am for using the
tools and technologies that enable me to rapidly develop robust
object-oriented systems that adhere to good design principles. You find
that you are unable or unwilling to apply certain tools and technologies
in a way that accomplishes these goals. I respect your decision. And I
agree with you that you should use what works for you. But that doesn't
mean someone who chooses a different way is, by definition, less
"agile". Or that combining good OO design with a small amount of
configuration is somehow more evil than the coupling from depending on
concretions.

The discussion really started, for me, with an examination of whether
certain common practices in TDD didn't in fact work counter to espoused
OO design principles, namely DIP and OCP. I used Robert Martin's copy
example as way of demonstrating what I thought was going wrong --
specifically, coupling and dependence on concretions was being designed
out of a class while testing and then put straight back in as a matter
of "convenience" to the production application. I have really been
advocating for looking seriously at this issue and examining whether
there are alternatives to what I see as leading to poor design.

I see the use of dependency inversion containers one possible solution.
My preference is to design a class test-first with any significant
dependencies based on interfaces. Test code supplies concrete
mocks/stubs implementing those interfaces to satisfy those dependencies.
With literally two or three lines of XML I can define the production
classes which satisfy those dependencies. When an instance of that class
is requested from the "container", it constructs the object with
appropriate instances of those classes to satisfy the dependencies. I
don't need to write any additional code to do it. That's code I also
don't have to change. Any time I can achieve my goals by *not* doing
something, I'll take that option.

As I said, I respect the fact that you don't agree with me. I do think
that perhaps leaves you with some hard choices that I possibly don't
have. But I'd certainly be interested in hearing solutions that a) don't
result in duplication in the code and b) don't reintroduce coupling. In
Martin's article /Principles and Patterns/, he named four symptoms of
rotting design -- fragility, rigidity, immobility, and viscosity. He
went on to say that these symptoms are "either directly, or indirectly
caused by improper dependencies between the modules of the software." To
prevent the symptoms, "the dependencies between modules in an
application must be managed." Dependencies do not propogate across
firewalls that are built using object-oriented design principles and
patterns. Principles like DIP, OCP, LSP, ISP, etc.

Why do so many believe they must compromise the designs that arise from
practice of TDD once they start to use a class in production? Are there
ways of bridging that gulf? That was the discussion I was hoping to have.

Regards,
Jim Cakalic
Post by Brill Pappin
Just to set the record sideways.
I (Brill) am mostly against Spring and Jim is mostly for Spring (as far
as I can tell).
The discussion is really about the use of Meta-data as a "glue", the
extent of it in frameworks like Spring and how that translates to the
principals of "agility".
- Brill Pappin
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-19 01:11:28 UTC
Permalink
Post by Jim Cakalic
Brill,
[...]

My apologies then for taking us off on a tangent :) I think Spring was
simply the "example product" that was getting the attention.
Post by Jim Cakalic
As I said, I respect the fact that you don't agree with me. I do think
that perhaps leaves you with some hard choices that I possibly don't
have. But I'd certainly be interested in hearing solutions that a) don't
result in duplication in the code and b) don't reintroduce coupling. In
Martin's article /Principles and Patterns/, he named four symptoms of
rotting design -- fragility, rigidity, immobility, and viscosity. He
I think my disagreement is really with the fact that IMO using config
files to the extent some frameworks do actually introduces "fragility,
rigidity, immobility, and viscosity" into the system by moving essential
parts of the code out of scope and into some external resource. This has
been my practical experience as well as my philosophical black sheep,
however it tends not to show up right away and usually manifests itself
after a product has become mature and/or complex.
Post by Jim Cakalic
went on to say that these symptoms are "either directly, or indirectly
caused by improper dependencies between the modules of the software." To
prevent the symptoms, "the dependencies between modules in an
application must be managed." Dependencies do not propogate across
firewalls that are built using object-oriented design principles and
patterns. Principles like DIP, OCP, LSP, ISP, etc.
I would agree with him as well, but I don't think the solution is adding
another layer or framework.
Post by Jim Cakalic
Why do so many believe they must compromise the designs that arise from
practice of TDD once they start to use a class in production? Are there
ways of bridging that gulf? That was the discussion I was hoping to have.
Ahh, and there you have to golden question. So far, in my experience
people don't feel they "must compromise the designs" but rather they
miss the point by focusing to close to the small part of the problem
they are working on or they get jaded to good practice or didn't
understand it in the first place and so the system takes on that
"biological mutation" pattern we're all familiar with, despite having
started out with the best intentions.

I've also noticed that developers will "compromise the design" simply
because a poorly written library/framework they really want to use
forces them to (an example of this is Quartz, which I like and use for
features but hate for it's design).

For me, it's a constant review of my own skills and work to make sure I
keep on track and even then it's easy to miss a beat by not bothering to
do something you know you should (like write a test or refactor some
sloppy code).

So far I have had the opportunity to work in several agile teams and
only one of them was really agile. I think it takes a certain amount of
fanaticism to maintain the discipline required (I say that despite
recent ideas that fanaticism is detrimental to a process) or at least if
not fanaticism, then an "anal" attention to the finer points of the
process your using and the point of doing it in the first place (I'm
lucky enough to work with such a fellow and he keeps me on my toes when
I get sloppy).


- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim Cakalic
2005-08-19 03:39:01 UTC
Permalink
Post by Brill Pappin
I think my disagreement is really with the fact that IMO using config
files to the extent some frameworks do actually introduces "fragility,
rigidity, immobility, and viscosity" into the system by moving essential
parts of the code out of scope and into some external resource. This has
been my practical experience as well as my philosophical black sheep,
however it tends not to show up right away and usually manifests itself
after a product has become mature and/or complex.
I would agree that there are some frameworks which are so "over-the-top"
configuration driven that they become the programming language. I worked
at a shop a few months back where this was happening. In that case the
framework was homegrown. Developers hardly even wrote Java any more.
They just collided on the single mammoth configuration file that
described the application -- every page, every transform, every SQL
statement. One file. At my current client they've become
configuration-averse because of one very bad experience with Coccoon.
Unfortunately, the've become like Mark Twain's cat: having sat once on a
hot stove lid, they will never sit on a hot stove lid again; but neither
will they sit on a cold one.

Martin's point, though, was that it is concrete dependencies /in the
code/ which are to blame for systems being hard to change, break in
unexpected ways when we do attempt to change them, and prevent us from
reusing what we've written before because it comes with way too much
/code/ baggage coupled to it.
Post by Brill Pappin
So far I have had the opportunity to work in several agile teams and
only one of them was really agile. I think it takes a certain amount of
fanaticism to maintain the discipline required (I say that despite
recent ideas that fanaticism is detrimental to a process) or at least if
not fanaticism, then an "anal" attention to the finer points of the
process your using and the point of doing it in the first place (I'm
lucky enough to work with such a fellow and he keeps me on my toes when
I get sloppy).
I cannot agree more that it takes discipline to adhere to the
principles, patterns, and techniques that result properly managed
dependencies within a system. This discipine is exactly what I think is
lacking when I talk of undermining good design by re-introducing
dependency on concretion. If a framework along with configuration can
help me to maintain the necessary design discipline then I certainly
think I ought to consider it.

Regards,
Jim


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Rob Park
2005-08-17 16:01:53 UTC
Permalink
"All" seems heavy handed to me. And so maybe not in some cases, but in most
cases I'm going to have an interface, so I can test without the real
dependency anyway. As a programmer of class A though, I don't think I
should know/care that I am actually coupled to class B (which implements
IB). All I need to know is IB. Spring nicely removes this complexity from
my compartmentalized view. So to me the cost of the XML config is worth it.

.rob.
Post by y***@jhrothjr.com
Unless you're very thorough about making _all_ of your objects
relate through the configuration file each and every time, you've
got two places to look whenever you want to figure out what's
coupled to what.
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
William Pietri
2005-08-17 06:54:29 UTC
Permalink
Post by Jim Cakalic
The statement was made previously that using tools like Spring and
meta-data expressed in XML was somehow something that no Agile
developer would do.
I didn't see it go by, but if someone said that, I'd say that they would
be stretching the point quite a bit.
Post by Jim Cakalic
I'm wondering which of the principles there
are intrinsically violated by Spring (DI containers in general) or XML
configurations. I'd refer to Simplicity (as described on that page) as a
principle that possibly supports leveraging the work of others ...
You shouldn't confuse simplicity with ease. A database, for example, may
be easy, but there are many megabytes of source code that make it work,
so it isn't simple.

Principle aside, I feel that frameworks driven by XML configuration are
also often not easy, on three levels. One is that the automatic
refactoring tools I've used have a hard time figuring out the
relationships that frameworks express in config files. Not being able to
completely trust my tools makes them much less valuable to me.

Another source of difficulty is that if I'm using a framework for
anything serious, I always end up having to get into the guts of it.
Maybe I won't have to actually change it, but I always end up having to
learn how it works so that I can humor it. And if I'm not using the
framework for anything serious, then the overhead generally isn't worth
it.

And the one I find most worrying is that frameworks come with a lot of
architectural assumptions, meaning that you lock in a good chunk of your
design when you pick them. This design inertia reduces agility. And
because teams often pick a framework at the beginning of a project, when
they know relatively little about the project, the selection of a
framework is relatively risky.


Of course, I haven't used Spring, so perhaps it's different. But for
Struts, or even for Servlet containers themselves, I've built things
with and without the frameworks, and I now prefer to keep my XML
configuration files to the absolute minimum, even if it means a little
more work in my code.

William
--
William Pietri <***@scissor.com>



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Berczuk
2005-08-17 14:19:12 UTC
Permalink
Post by William Pietri
Of course, I haven't used Spring, so perhaps it's different. But for
Struts, or even for Servlet containers themselves, I've built things
with and without the frameworks, and I now prefer to keep my XML
configuration files to the absolute minimum, even if it means a little
more work in my code.
My team has been discussing the issue of how to test apps with Spring,
so this is a timely discussion.
I am coming to the conclusion that there isn't really a single answer.

Coding the connections in your test setup method makes the
configuration more explicit, but doing it for complicated sets of
dependencies means that there is lots of code in the test that really
isn't informative (and leads to duplication for various tests).

Having a seperate XML config for testing vs production means that you
have to keep the two in synch for the parts that are NOT related to
the test.

One thing I've come to realize is that the more testable your code is,
the 'cleaner' the design/architecture, so maybe this is the real
"test" to use when deciding how to set up your tests. If you can write
your tests so that they load a different spring config simply, and/or
hardwire the dependencies, then you're fine. If either/both are hard
maybe you need to rethink your design?

Steve
--
Steve Berczuk | ***@berczuk.com | http://www.berczuk.com
SCM Patterns: Effective Teamwork, Practical Integration
www.scmpatterns.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-17 17:56:33 UTC
Permalink
[...]
Post by Steve Berczuk
One thing I've come to realize is that the more testable your code is,
the 'cleaner' the design/architecture, so maybe this is the real
"test" to use when deciding how to set up your tests. If you can write
your tests so that they load a different spring config simply, and/or
hardwire the dependencies, then you're fine. If either/both are hard
maybe you need to rethink your design?
A suggestion:

If you use a hard-wired method of testing, then you can refactor your
test suites at will and simplify how things (the tests) work, the cost
of course will be verbosity which can be its own issue.

Keep in mind that you do not want external dependancies that your unit
tests have to use if you can help it.
Also, a lot of your test setup will not really be important to the test
itself (a lot of infrastructure) and can be pulled up into a base
TestCase class, this will keep the test easy to read while still
allowing the specific (and concrete) references that are so important to
a clean test and agile code.

- Brill Pappin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Berczuk
2005-08-18 14:41:35 UTC
Permalink
Post by Brill Pappin
[...]
Post by Steve Berczuk
One thing I've come to realize is that the more testable your code is,
the 'cleaner' the design/architecture, so maybe this is the real
"test" to use when deciding how to set up your tests. If you can write
your tests so that they load a different spring config simply, and/or
hardwire the dependencies, then you're fine. If either/both are hard
maybe you need to rethink your design?
If you use a hard-wired method of testing, then you can refactor your
test suites at will and simplify how things (the tests) work, the cost
of course will be verbosity which can be its own issue.
True enough, though in theory you could refactor the XML
configurations (which mostly is about setting attributes) as well.
Tools aren't all there yet, but...

I do agree about the verbosity/cost issue.
Post by Brill Pappin
Keep in mind that you do not want external dependancies that your unit
tests have to use if you can help it.
This is kind of related to my comment that a complicated test setup is
an indicator of a possibly too complex design...
Post by Brill Pappin
Also, a lot of your test setup will not really be important to the test
itself (a lot of infrastructure) and can be pulled up into a base
TestCase class, this will keep the test easy to read while still
allowing the specific (and concrete) references that are so important to
a clean test and agile code.
Yes, but you can also have the base test case load the correct config file....
As I said, I'm still not sure if I have a 'rule' about this yet. I do
think that writing code so that it is easy to test is good, and I've
observed that one tends to get into these issue (configuration v hard
coding, etc) more when you DON'T do test first than when you do....

Steve
--
Steve Berczuk | ***@berczuk.com | http://www.berczuk.com
SCM Patterns: Effective Teamwork, Practical Integration
www.scmpatterns.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-17 17:48:29 UTC
Permalink
Ok, that one was mine...

What I said was:
- "IMO injecting concrete code from "meta-code" is an anti pattern in
and of itself."
[MessageID=***@pappin.ca]

- "I don't know if "wire objects together by configuration" is really a
marker for DI or even a good thing for an agile developer to be doing..."
[MessageID=***@pappin.ca]


as well as several other statements of opinion along the same lines.

- Brill Pappin
Post by William Pietri
Post by Jim Cakalic
The statement was made previously that using tools like Spring and
meta-data expressed in XML was somehow something that no Agile
developer would do.
I didn't see it go by, but if someone said that, I'd say that they would
be stretching the point quite a bit.
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
jgo456
2005-08-18 21:19:54 UTC
Permalink
Post by William Pietri
Another source of difficulty is that if I'm using
a framework for anything serious, I always end up
having to get into the guts of it.
Maybe I won't have to actually change it, but I
always end up having to learn how it works so that
I can humor it. And if I'm not using the framework
for anything serious, then the overhead generally
isn't worth it.
And the one I find most worrying is that frameworks
come with a lot of architectural assumptions,
meaning that you lock in a good chunk of your
design when you pick them.
I have to pipe up because these comments match so closely my first
encounters with Cocoa.

OT1H, digging into the guts violates the principle of
"encapsulation". If it's a decent framework, you should only be
looking at thoroughly documented interface.

But the principle of encapsulation makes it nearly impossible to get
an impression of how a particular class from a framework can be
reasonably used in various contexts. Even after seeing a number of
examples, it's sometimes difficult to extrapolate.

The occasional comment that such and such a method should be over-
ridden does little good if you can't see a layer deeper to understand
what the framework architects had in mind as reasonable
implementations, and hence, over-rides.

Most of the OO documentation I've seen has been intentionally hyper-
atomistic, giving little insight into context. It's almost as if
your set of tinker toys had hundreds of different kinds of pieces
with different kinds of connection mechanism, some you simple push
together, others require a quarter-turn after insertion, others screw
together with coarse threads, some with fine threads... at various
pitches, with different thread profiles..., still others require
special connector objects, or two kinds of connector objects working
together (only the fact that they need to be used together is not
documented), etc.

It requires a great deal of imagining how the framework architects
were thinking, and it is very easy for one's imaginings to diverge
from what the architects' thinking actually was/is (especially when
they use terms in ways or with connotations different from your
expectations).




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-19 01:18:51 UTC
Permalink
jgo456 wrote:
[...]
Post by jgo456
Most of the OO documentation I've seen has been intentionally hyper-
atomistic, giving little insight into context. It's almost as if
your set of tinker toys had hundreds of different kinds of pieces
with different kinds of connection mechanism, some you simple push
together, others require a quarter-turn after insertion, others screw
together with coarse threads, some with fine threads... at various
pitches, with different thread profiles..., still others require
special connector objects, or two kinds of connector objects working
together (only the fact that they need to be used together is not
documented), etc.
It requires a great deal of imagining how the framework architects
were thinking, and it is very easy for one's imaginings to diverge
from what the architects' thinking actually was/is (especially when
they use terms in ways or with connotations different from your
expectations).
For that very reason, I'm slowly coming to the conclusion that
frameworks should be as small, light weight and decoupled as much as
possible... give me a framework that does some specific job (and does it
obviously), and leave it at that.. I don't need anything more complex
and I can pick and choose which ones I want to use. Of course, this
assumes the framework is sufficiently decoupled that I can mix and match
components as I need them.

- Brill Pappin




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-16 23:48:06 UTC
Permalink
But he doesn't say do the *whole thing* first does he (haven't read it yet)?

- Brill Pappin
Post by Jim McMaster
Post by Hugo Garcia
So, what you guys are saying is to refactor without unit test so that
the code can be tested and once you have refactored enough so that
there are places in the refactored code where you can hook basic tests
then do TDD to finish the big refactoring of that part of the code you
are working on?
This is the approach suggested by Michael Feathers in his book, "Working
Effectively With Legacy Code". He shows a lot of small dependency-breaking
refactorings that enable getting the code under test. Then you can get to
the real refactoring.
I highly recommend this book. Feathers did an excellent job.
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jim McMaster
2005-08-16 23:56:35 UTC
Permalink
Post by Brill Pappin
But he doesn't say do the *whole thing* first does he (haven't read it yet)?
- Brill Pappin
No...Feathers lays out several dependency-breaking techniques, and "safe"
refactoring steps that try to get the code into good enough shape to get
unit tests in place. Then you can do more aggressive refactoring.
--
Jim McMaster
mailto:***@comcast.net




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Langr
2005-08-17 03:39:02 UTC
Permalink
I think I remember being there. It's all a blur, since I was trying to
get to the airport after having my talk rescheduled twice and foisted
to late Saturday afternoon.

The main thrust of the experience report was that it's important for
developers to understand the forces that drive the need for mocks, and
that they understand the design concessions mocks inherently introduce
(however minor they may be). Overuse or poor use of mocks can cause as
many problems as they're supposed to solve. I've seen overmocking lead
to an extremely brittle and rigid system.

Nonetheless, I'll prefer having tests and a few isolated design
concessions to no tests and a "cleaner" design any day. So I'm ok with
the judicious use of such mocks in a system.

The reaction to this message was twofold: a) most people were nodding
heads about the potential problems that using mocks can introduce and b)
the authors of the original mock paper suggested that I was ignoring
their primary intended use of mocks, which is to explore design (I think
the term has been broadened a bit from the original intent, to their
apparent dismay).

Jeff
Langr Software Solutions
http://langrsoft.com
author, Agile Java: Crafting Code With Test-Driven Development
Post by Jim Cakalic
My concern is I see this pattern occuring
(adding the no-arg constructor) frequently and even advocated by many as
the "right" way to design. I referenced Jeff Langrs experience report to
the 2004 Agile Development Conference. Were you there? Do you recall
what the reaction was?
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ramon Leon
2005-08-17 17:19:29 UTC
Permalink
Post by William Pietri
Principle aside, I feel that frameworks driven by XML
configuration are also often not easy, on three levels. One
is that the automatic refactoring tools I've used have a hard
time figuring out the relationships that frameworks express
in config files. Not being able to completely trust my tools
makes them much less valuable to me.
To piggy back this comment a bit, I feel that the current xml disease
infecting the java and csharp worlds seems like homebrew ad hoc dynamic
languages invented to try and give statically typed languages more
runtime flexibility. Java feel too hard and inflexible, let's invent a
mini language in xml to make it simpler, next thing you know you're
writing more config files than code, each invented by different groups
of people with different ideas on how their syntax should be structured.


How many different frameworks do we have to learn and configure before
we simply abandon the language and use something better. I'd rather
just work in a more dynamic language that didn't force me to jump out to
xml every time I needed some flexibility at runtime, maybe Smalltalk or
Ruby. Ruby on Rails was invented specifically as a reaction against xml
config files, that should speak volumes about the distaste xml leaves
many people.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Brill Pappin
2005-08-17 18:00:18 UTC
Permalink
<clap, clap, clap>

- Brill Pappin
Post by Ramon Leon
Post by William Pietri
Principle aside, I feel that frameworks driven by XML
configuration are also often not easy, on three levels. One
is that the automatic refactoring tools I've used have a hard
time figuring out the relationships that frameworks express
in config files. Not being able to completely trust my tools
makes them much less valuable to me.
To piggy back this comment a bit, I feel that the current xml disease
infecting the java and csharp worlds seems like homebrew ad hoc dynamic
languages invented to try and give statically typed languages more
runtime flexibility. Java feel too hard and inflexible, let's invent a
mini language in xml to make it simpler, next thing you know you're
writing more config files than code, each invented by different groups
of people with different ideas on how their syntax should be structured.
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2005-08-20 00:45:06 UTC
Permalink
Post by Tunca Bergmen
I am writing a simple OR mapper. I have a class that generates insert sql
according to metadata. First I wrote a test which knows the correct sql and
compares it to the generated one. But the test failed because in the
generated sql, column order changes randomly. My class generates correct sql
string but it is different from the hard-coded one. Any ideas on how to
formulate the test to overcome this problem?
In _JUnit Recipes_, I refactored INSERT statements to objects that
describe the statement of this format:

InsertStatementDescription
String tableName
Map<String, Object> insertValues

I find these easier to compare to one another than SQL Strings, for
exactly the reason you mention. In this case, since the corresponding
insertValues.keySet()s are both Sets, the order in which the column
names appear doesn't matter.

I hope that helps.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

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

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

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