Discussion of the eXtreme Programming practice of TestDrivenDevelopment

Jim Cakalic | 1 Dec 2005 04:42

Re: Spring DI Code Reuse was Am I doing too much refactoring?

Ian D. Stewart wrote:

>Slightly off-topic, I've recently started working with the Spring 
>Framework and the concept of dependency injection, and one of the 
>pleasant surpirses I've encountered, in addition to a much cleaner 
>codebase, is a significant increase in code re-use.  Because each of the 
>layers (Model, DAO, Service, Application Context) is able to exist 
>independant of the layer above it, I'm finding that code that I have 
>written for this one project is also being leveraged in other projects, 
>one of which I am not even involved in!
>
>On the down side, this does play havoc with tracking 
>accomplishments/progress on a per-project basis... :)
>  
>
Hi, Ian.

Can you talk more about your experiences in this area?

I'm particularly interested as I am consulting at a company that 
practices TDD. The architects are quite keen on the application of 
Robert Martin's principles of OO design. Yet they regularly subvert 
dependency inverting designs (IMO) arrived at by TDD and application of 
design principles by instantiating concrete classes in convenience 
constructors. Or indiscriminately using what I think Jeff Langr calls 
deferred factory mocking by having protected methods that instantiate 
specific concrete instances of dependencies that they then override in 
test subclasses so that they can inject a different object.

Anyway, I and some others have been trying to get the architects to

(Continue reading)

Adam Sroka | 1 Dec 2005 06:21

Re: Spring DI Code Reuse was Am I doing too much refactoring?


Jim Cakalic <james.cakalic <at> charter.net> said:
> 
> Anyway, I and some others have been trying to get the architects to 
> consider using Spring's BeanFactories as a means of easing the 'pain' of 
> sticking with DIP. Better designs (again IMO), greater decoupling. And 
> since 2006 is supposed to be their 'year of reuse', if Spring can be 
> shown to provide greater reusability then it may get more play.
> 

This is one of the better reasons for using Spring that I have heard. I am
always suspicious of frameworks. In order for a framework to be the simplest
solution a couple things have to be true: The framework itself has to be well
written so that it is flexible enough to solve a lot of problems without
getting in the way, and the problem that you are solving must be very close to
the problem that the framework was designed to solve. Most frameworks and/or
applications thereof fall short on one or both of these. The first is
generally true of Spring when well applied, which is why I think its current
popularity is deserved. And, it sounds like the problem you are solving,
adding consistency to improve reuse in a project that already uses dependency
injection extensively, is exactly what Spring was intended to do.  

> If anyone else has experiences related to use of Spring or another 
> dependency injection container and how it has promoted the practices of 
> TDD, yielded better designs, or fostered reuse, please join in.
> 

I have been using Spring, and I like it. It has two potential shortcomings
that I see. First, like many popular technologies, it lends itself very easily
to the Golden Hammer antipattern. Avoid unnecessary injections (You'll end up

(Continue reading)

Jim Cakalic | 6 Dec 2005 05:32

Re: Spring DI Code Reuse was Am I doing too much refactoring?

Adam, thanks for your comments.

Adam Sroka wrote:

>I have been using Spring, and I like it. It has two potential shortcomings
>that I see. First, like many popular technologies, it lends itself very easily
>to the Golden Hammer antipattern. Avoid unnecessary injections (You'll end up
>with track marks ;-> Second, if you use the XML descriptor to deploy
>dependencies, you'll have to be quite dilligent about maintaining that
>descriptor or you'll end up with a big mess on your hands. This is a criticism
>of declarative programming with XML generally, but Spring XML files can get
>big and messy when compared with EJB, for example (Nothing is as bad as a
>poorly written ant script though. That's why I'm a maven convert.) 
>  
>
When you say be diligent about maintaining the XML descriptor, are you 
referring to possible errors in the descriptor itself? Or are you 
talking about cruft building up due to incremental change and 
refactoring? What do you think about a unit test whose only job is to 
instantiate the BeanFactory with the production beans.xml? Also, I do 
appreciate your advice about avoiding unnecessary injections. So far, 
our practice has been to inject a) objects for which we found a reason 
to use interfaces during TDD, and b) objects that would otherwise have 
to be passed through multiple layers to get to the right place -- say, 
for example, a thread-specific JDBC Connection or a Hibernate Session.

>Spring does lend itself to TDD. In particular the ability to inject mock
>objects is kind of nifty. Mocks themselves can become Golden Hammers, however.
>I remember when I was first learning about mocks and I had already been doing
>TDD for a while. I discovered that I could write a test that assumes a certain

(Continue reading)

Adam Sroka | 6 Dec 2005 18:27

Re: Spring DI Code Reuse was Am I doing too much refactoring?


Jim Cakalic <james.cakalic <at> charter.net> said:

> 
> When you say be diligent about maintaining the XML descriptor, are you 
> referring to possible errors in the descriptor itself? Or are you 
> talking about cruft building up due to incremental change and 
> refactoring? 

The latter. XML files can get long and messy. Spring does have an extension
mechanism that can make this easier, but it is not always the simplest
solution. In my experience it is very important that you organize your XML
file well. Use communicative names and put things in some logical order
(According to use is best, but alphabetical works too.) Splitting up the
descriptor in some logical fashion is also a good idea (There are a couple of
mechanisms for this, but XML entities are the most straightforward.) 

Again, these are ideas that apply to any XML descriptor; they are not
exclusive to Spring. 

> What do you think about a unit test whose only job is to 
> instantiate the BeanFactory with the production beans.xml? 

Sounds like a solid idea to me. I may have to steal that one. 

> Also, I do 
> appreciate your advice about avoiding unnecessary injections. So far, 
> our practice has been to inject a) objects for which we found a reason 
> to use interfaces during TDD, and b) objects that would otherwise have 
> to be passed through multiple layers to get to the right place -- say,

(Continue reading)

Gishu Pillai | 5 Dec 2005 10:33

Picon

Re: Spring DI Code Reuse was Am I doing too much refactoring?

> objects is kind of nifty. Mocks themselves can become Golden Hammers,
> however.
> I remember when I was first learning about mocks and I had already been
> doing
> TDD for a while. I discovered that I could write a test that assumes a
> certain
> interface method, have the IDE generate the interface, mock the interface,
> and
> then get a green bar. Then I was scratching my head... Did that mean I could
> go home?

I am using mocks at the moment and I feel that you can't go home yet ;)
You need 2 more tests
• for the implementation of the interface you just mocked.
• another test to see if that implementation is hooked up to the rest
of your system for the real-life use of your interface.

-- Gishu

------------------------ Yahoo! Groups Sponsor --------------------~--> 
1.2 million kids a year are victims of human trafficking. Stop slavery.
http://us.click.yahoo.com/WpTY2A/izNLAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

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

(Continue reading)

Adam Sroka | 5 Dec 2005 17:42

Re: Spring DI Code Reuse was Am I doing too much refactoring?


Gishu Pillai <gishu.pillai <at> gmail.com> said:

> > objects is kind of nifty. Mocks themselves can become Golden Hammers,
> > however.
> > I remember when I was first learning about mocks and I had already been
> > doing
> > TDD for a while. I discovered that I could write a test that assumes a
> > certain
> > interface method, have the IDE generate the interface, mock the interface,
> > and
> > then get a green bar. Then I was scratching my head... Did that mean I could
> > go home?
> 
> I am using mocks at the moment and I feel that you can't go home yet ;)
> You need 2 more tests
>  for the implementation of the interface you just mocked.
>  another test to see if that implementation is hooked up to the rest
> of your system for the real-life use of your interface.
> 

Well, I was being slightly facetious. The real point is that TDD turns coding
on its head, because you test from the outside then code just enough guts to
get a green bar. Just when you've got that figured out, mocks turn TDD on its
head, because if you test from the outside you are superficially sucessful
(But not really.) So, you have to test drive in layers much as you would have
coded in layers before you learned TDD. IMHO, it is better *not* to use mocks
because the solution is likely to be more complicated than strictly necessary.
If you come to a point where layering is necessary (Because it makes the
overall solution simpler... or at least that is my preferred definition of

(Continue reading)

Rob Park | 1 Dec 2005 22:01

Picon

Re: Spring DI Code Reuse was Am I doing too much refactoring?

I've been using Spring for a while now.  On a couple different Java projects 
in the past and now on a .Net project.  If you haven't already read "J2EE 
w/o EJB", I'd highly recommend it.  I've experienced a lot of what Rod 
Johnson says in there to be true.

Before I really started to get into mocks, I used a lot of stubs and Spring 
was a great way to improve testability by injecting the right object at the 
right time.  Now I'm more into using Nmocks that I configure right in the 
test, so I don't really need to inject anything via spring as I'm generally 
doing it manually in the test.  1 draw back is the test is a little bulkier, 
but that hasn't been a problem so far.  In any case, even having Spring 
inject a production DAO rather than doing it manually all over the place is 
a big code readability improvement in my mind.  Not to mention, it's just a 
really convenient factory to have (e.g. say you have a command pattern that 
needs a type of class by name w/ a common interface), so you don't need to 
manually test and code your own reflection stuff.

The biggest drawbacks (cautions really, not big problems... IMO) are you 
have to be aware of and understand the singleton implications from the 
Spring container; you have to figure out how to best configure and store 
your xml context files, since you can configure them 1,000+ ways (or so it 
seems); and you need to ensure (in other words _test_) your production 
context is valid in order to avoid runtime errors.

We're a test-driven shop. It works for us anyway.  

.rob.

>
>If anyone else has experiences related to use of Spring or another

(Continue reading)

Dave Rooney | 1 Dec 2005 12:26

Picon

Re: Spring DI Code Reuse was Am I doing too much refactoring?

Jim Cakalic wrote:

[snip]

>Hi, Ian.
>
>Can you talk more about your experiences in this area?
>
>I'm particularly interested as I am consulting at a company that 
>practices TDD. The architects are quite keen on the application of 
>Robert Martin's principles of OO design. Yet they regularly subvert 
>dependency inverting designs (IMO) arrived at by TDD and application of 
>design principles by instantiating concrete classes in convenience 
>constructors. Or indiscriminately using what I think Jeff Langr calls 
>deferred factory mocking by having protected methods that instantiate 
>specific concrete instances of dependencies that they then override in 
>test subclasses so that they can inject a different object.
>
>Anyway, I and some others have been trying to get the architects to 
>consider using Spring's BeanFactories as a means of easing the 'pain' of 
>sticking with DIP. Better designs (again IMO), greater decoupling. And 
>since 2006 is supposed to be their 'year of reuse', if Spring can be 
>shown to provide greater reusability then it may get more play.
>
>If anyone else has experiences related to use of Spring or another 
>dependency injection container and how it has promoted the practices of 
>TDD, yielded better designs, or fostered reuse, please join in.
>
>Perhaps we should take it to a new topic?
>

(Continue reading)

Tony Nassar | 1 Dec 2005 05:04

RE: Convincing Others?

Here's just an example. I did a similar thing today, simply because I was
getting sick of being unable to test my Action classes without hitting the
database (I played no role in the design). I'm going one Action at a time.
That's enough. There's also some good stuff in J.B. Rainsberger's Junit
Recipes about testing rendered JSPs; this has been especially useful to me,
since I'm not a JSP guy, yet the JSPs have landed in my lap. 

Apropos, if I were to ask, "May I add the Spring JAR to the lib directory?"
the answer would be no. So I don't ask. 

> -----Original Message-----
> From: testdrivendevelopment <at> yahoogroups.com 
> [mailto:testdrivendevelopment <at> yahoogroups.com] On Behalf Of 
> Jim Cakalic
> Sent: Wednesday, November 30, 2005 10:42 PM
> To: testdrivendevelopment <at> yahoogroups.com
> Subject: Re: [TDD] Spring DI Code Reuse was Am I doing too 
> much refactoring?
> 
> Ian D. Stewart wrote:
> 
> >Slightly off-topic, I've recently started working with the Spring 
> >Framework and the concept of dependency injection, and one of the 
> >pleasant surpirses I've encountered, in addition to a much cleaner 
> >codebase, is a significant increase in code re-use.  Because each of 
> >the layers (Model, DAO, Service, Application Context) is 
> able to exist 
> >independant of the layer above it, I'm finding that code that I have 
> >written for this one project is also being leveraged in 
> other projects,

(Continue reading)

Hristo Deshev | 1 Dec 2005 07:47

Picon

Re: Convincing Others?

Hi everyone,

I want to add another "me too" to the "Just do it" advice.  I have never
asked anyone at my past 4 jobs if it was OK to do TDD.  I believed this was
helping me do a better job, and I just did it.  Nobody told me that I was
doing something wrong or I was harming somebody else.  I was never told to
stop doing it.  Nobody complained that I was going slower than others
because of all that testing (maybe because I didn't go slower :->>)

On 12/1/05, Tony Nassar <devl <at> anthonynassar.com> wrote:

> <snip />
> Apropos, if I were to ask, "May I add the Spring JAR to the lib
> directory?"
> the answer would be no. So I don't ask.

Similar to my experience.  I don't think I would have gotten a "no" answer,
but I don't think adding libraries that will help me work better (libraries
that won't be needed for the final build) is even supposed to be
questioned.  I usually go the "Oh, and don't forget to get
nunit.framework.dll and nmock.dll when you build the solution" way.

Hristo Deshev
http://blogs.telerik.com/blogs/twisted_asp_net/

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

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/2jUsvC/tzNLAA/TtwFAA/NhFolB/TM

(Continue reading)

Return

Return to gmane.comp.programming.test-driven-development.

Project Web Page

Discussion of the eXtreme Programming practice of TestDrivenDevelopment

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane