Are you really using JUnit during your development?

[Cédric Beust ♔]

On 8/15/06, Jeff Langr <jeff@...> wrote:
>
> Cedric Beust wrote:
> > And by the way, for those of you (not you, JB) who make such claims, I
> have
> > a few projects for you that simply *can't* be done with TDD.
> >
> Greetings Cedric,
>
> Can you toss out a couple of those examples?


Sure, how about a Java ME application?

--
Cédric


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



 
Yahoo! Groups Links

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

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

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

[Simon Chappell]

On 8/15/06, Cédric Beust ♔ <cbeust@...> wrote:

> Hi Jeff,
>
> On 8/15/06, Jeff Langr <jeff@...> wrote:
> >
> >
> > I still try to do it 100%. It's a goal for me, not an absolute. I derive
> > a considerable increase in development speed from doing this, so I'm
> > baffled at the continuing claims that it's "unhealthy" or
> > "unprofessional."
>
>
> Actually, the only claim that was made on this thread was that it was
> unprofessional *not* to do TDD all the time or to have less than 90% code
> coverage.

It _is_ unprofessional to hand over untested code to a customer. TDD
is the best way that _I_ know of to generate quality, tested code.

>  My follow-up claim is that anyone who says this has never really worked on
> the kind of real-world projects that I (and hundreds of thousands of other
> developers out there) are involved in on a daily basis.

17 years and lots of "real" projects and I _still_ think that TDD far
exceeds the wonders of sliced bread. :-)

> Having said that, I agree with JB that imposing a TDD mindset on junior
> developers is certainly a good discipline, if only because when they can't
> do TDD, they have to come up with a good justification, which is usually the
> start of a very healthy discussion.

As one who mentors junior Java developers, I can only 100% agree with this.

Simon

--
www.simonpeter.org


 
Yahoo! Groups Links

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

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

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

[Simon Chappell]

On 8/15/06, J. B. Rainsberger <jbrains@...> wrote:
> Simon Chappell wrote:
>
> > Actually, I really meant it when I said that without TDD, you'll only
> > ever write code that is "good enough". Quality code only comes from
> > using TDD.
>
> So quality code /only/ comes from TDD? I have 100 formal methods guys on
> Line 4 waiting to speak with you....

Please don't try to tell me that formal methods never produce bad
software. I am not falling for that.

Simon

--
www.simonpeter.org


 
Yahoo! Groups Links

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

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

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

[Simon Chappell]

On 8/15/06, J. B. Rainsberger <jbrains@...> wrote:

> Brett L. Schuchert wrote:
>
> >  >> From: Simon Chappell <simonpeterchappell@...
> > <mailto:simonpeterchappell%40gmail.com>>
> >  >> religion. I'm sure it's possible to write code that is "good enough"
> >  >> without TDD, but it'll never be high quality.
> >
> > You just made a strong claim:
> > Without TDD you'll never be high quality
>
> I'm pretty sure Simon was drunk when he wrote that, and he meant
> something else, didn't you, Sime?

I've been off the demon drink for about thirteen years now, so you
must have mistaken me for some other highly opinionated Englishman.
:-)

Simon

--
www.simonpeter.org


 
Yahoo! Groups Links

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

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

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

[James Grenning]

Hello Cedric

The people at Sony Erickson might disagree.  Here is a link to

Sony Ericsson Mobile JUnit 1.0 for Java ME CLDC phones

http://developer.sonyericsson.com/site/global/newsandevents/latestnews/newsjuly06/p_mobile_juint1.0_javame_cldc.jsp

In a mobile or embedded environment, one of the problems is
dependencies on hardware and execution environment specifics.  Testing
the conections and interactions with the hardware will likely require
some manual testing, just like testing a GUI requires someone to test
the look and feel by looking and feeling.

James

----
James Grenning
Object Mentor, Inc.
www.objectmentor.com
----

--- In junit@..., "Cédric Beust â™" " <cbeust@...> wrote:
>
> On 8/15/06, Jeff Langr <jeff@...> wrote:
> >
> > Cedric Beust wrote:
> > > And by the way, for those of you (not you, JB) who make such
claims, I

> > have
> > > a few projects for you that simply *can't* be done with TDD.
> > >
> > Greetings Cedric,
> >
> > Can you toss out a couple of those examples?
>
>
> Sure, how about a Java ME application?
>
> --
> Cédric
>
>
> [Non-text portions of this message have been removed]
>

 
Yahoo! Groups Links

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

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

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

[Andreas G Guther]

There is always the possibility to define your API with Interfaces and thus have it as user friendly as possible without exposing any additional methods that were written in the actual implementation for the purpose of testing the class.

 

Andreas

 

________________________________

From: junit@... [mailto:junit@...] On Behalf Of Cédric Beust ?
Sent: Tuesday, August 15, 2006 1:22 PM
To: junit@...
Subject: Re: [junit] Test-friendly, but not caller-friendly?

 

On 8/15/06, J. B. Rainsberger <jbrains@... <mailto:jbrains%40rogers.com> > wrote:

>
> Cédric Beust ♔ wrote:
>
> > Still, sometimes, I find that putting the emphasis on testing first can
> > sometimes impact the final interface of your solution adversely. In
> other
> > words: your code ends up being more test-friendly than caller-friendly.
>
> Objection: speculation. Show me that API. I've never seen a
> test-friendly API that wasn't also caller-friendly. (Certainly I've
> never built such a theoretical monstrosity.)

I don't have a specific example to show you right now, but I can make one up
:-)

Dependency injection is handy for testing, but it can sometimes expose more
than the user needs to know (something that can be addressed with a
judicious use of overloaded methods).

I have also sometimes seen class constructors gaining a lot of parameters or
new setters just for the purpose of testing.

Note that I'm actually playing the devil's advocate here, since I'm actually
fine with adding some extra weight to my classes to make them more testable,
but I try to limit this extra bagage to places that don't appear in the
public interface. Not everybody does, though.

I suspect we would see more of this problem if TDD became popular, but I'll
stop here before you say "speculation" again :-)

--
Cédric
http://testng.org <http://testng.org>

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



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





 
Yahoo! Groups Links

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

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

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

[Cédric Beust ♔]

The problem is not the testing framework (there are various flavors of JUnit
available for CDC and CLDC), it's the fact that MIDP and emulators
(including Ericsson's) have absolutely no way to be driven programmatically,
which makes automated testing a very challenging (if not impossible in some
cases) task.

Sun didn't design MIDP to be easily testable, unfortunately...

--
Cedric


On 8/16/06, James Grenning <jwgrenning@...> wrote:

>
> Hello Cedric
>
> The people at Sony Erickson might disagree.  Here is a link to
>
> Sony Ericsson Mobile JUnit 1.0 for Java ME CLDC phones
>
>
> http://developer.sonyericsson.com/site/global/newsandevents/latestnews/newsjuly06/p_mobile_juint1.0_javame_cldc.jsp
>
> In a mobile or embedded environment, one of the problems is
> dependencies on hardware and execution environment specifics.  Testing
> the conections and interactions with the hardware will likely require
> some manual testing, just like testing a GUI requires someone to test
> the look and feel by looking and feeling.
>
> James
>
> ----
> James Grenning
> Object Mentor, Inc.
> www.objectmentor.com
> ----
>
> --- In junit@..., "CÃ(c)dric Beust â™" " <cbeust@...> wrote:
> >
> > On 8/15/06, Jeff Langr <jeff@...> wrote:
> > >
> > > Cedric Beust wrote:
> > > > And by the way, for those of you (not you, JB) who make such
> claims, I
> > > have
> > > > a few projects for you that simply *can't* be done with TDD.
> > > >
> > > Greetings Cedric,
> > >
> > > Can you toss out a couple of those examples?
> >
> >
> > Sure, how about a Java ME application?
> >
> > --
> > Cédric
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

--
Cédric


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



 
Yahoo! Groups Links

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

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

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

[Carl Hume]

On 8/15/06, Cédric Beust ♔ <cbeust@...> wrote:
>
>
> I simply reject the negative side of this claim: just because you don't do
> TDD doesn't mean that your code is not testable. If the developer is
> experienced, she will produce testable code, whether she uses TDD or not.
>






 How do you define "experienced"?  I've encountered many "experienced"
developers that do nothing of the sort.  They produce testable applications,
but not testable code.

And as an experienced developer, she will always consider all her options
> before picking a methodology, which is always more healthy than saying "I
> do
> TDD 100% of the time".
>


I agree - experienced developers always consider their entire toolset, and
make use of the most appropriate for the job at hand.

Cheers!
Carl

--
http://genomescampaigns.blogspot.com


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



 
Yahoo! Groups Links

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

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

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

[Elliotte Harold]

Andreas Guther wrote:
> There is always the possibility to define your API with Interfaces and thus have it as user friendly as possible without exposing any additional methods that were written in the actual implementation for the purpose of testing the class.
>

YUCK! That's like making your tech support user friendly by outsourcing
it to trained professionasl in India rather than letting your clients
talk directly to the developers. There's a ton of theory (i.e.
rationalizations) to support doing that, and it's completely
counterproductive in practice.

Interfaces are very popular among the most theoretical programmers: i.e.
exactly the sort of programmers who are likely to write books, read
books about OO theory, and hang out on lists like this one. However in
my experience concrete classes are much simpler and much preferred by
the vast majority of pragmatic programmers just getting their jobs done.

I can certainly see how making a class test-friendly could make it less
caller-friendly. In fact, exactly how to do that is the subject of
another perma-thread on this list. exposing methods purely for the
convenience of testers expands a class's interface and makes it harder
to learn, use, and understand. Minimal interfaces are simpler to
understand and learn. Exposing additional methods purely for test
convenience is very counter-productive to caller-convenience. The only
public parts of a class's interface should be things that are relevant
to client programmers.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

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

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

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

[Jeff Langr]

Cédric Beust ♔ wrote:
> Sure, how about a Java ME application?
>
>  
Greetings Cedric,

I've never worked on an ME application, so I can't really speak to it. A
web search reveals a couple other efforts to support unit testing, but
it's tough to gauge how successful people have been with them.

Were I doing J2ME development, I'd find a way to unit (not integration)
test the bulk of the app irrespective of MIDP. I looked at a number of
J2ME examples. I have yet to come across one that isn't poorly designed
and coded, with classes combining all sorts of concerns. UI +
communications logic, command handling + parsing, game geometry/physics
+ display logic, etc. All that parsing and math is easy to get wrong.
It's also very usable in other contexts if not married to the ME
environment.

I don't see a reason why the majority of the classes in an ME app
couldn't be broken down and unit-tested, and I found a few links that
suggest some people are doing just that. Presumably, any MIDP-specific
stuff--which should be a small portion of the app--would have to be
mocked and integration tested (and probably manually, based off what
you're telling me).

But there'd still be considerable benefit to unit testing the rest of
the app. That's conjecture; I'd like to hear from a hardcore TDD
developer who's actually done this. It could be a mess and useless
endeavor, which says more about the quality of the environment than the
value of TDD.

I've recently worked with customers using environments that don't
support unit-testing very well. Working with a FoxPro developer, we were
able to unit-test a good percentage (not all) of the code by
restructuring it a bit. What I found interesting is that a light almost
immediately went on in the Foxpro developer's head about the design
benefits of doing so.

If the environment doesn't support it, obviously you can't do complete
unit-testing. One thing that is coming out of the interest in unit
testing is that the tool makers are figuring out how to design
frameworks that more readily support testing (e.g. Spring), for better
or worse.

I seriously doubt that it'd be necessary punt on an entire ME
application. And I suspect that any overhead related to how the
environment had to be set up would be quickly paid off by the ability to
"close off" large portions of the app.

Jeff

--
Langr Software Solutions
http://langrsoft.com
Agile Java: Crafting Code With Test-Driven Development



 
Yahoo! Groups Links

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

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

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

[Andreas G Guther]

As always a hammer is not the only solution for all carpenter’s problems.  Know your tools, and know your IDE.  IDEs like Eclipse and IntelliJ make it very easy to generate an interface from an existing class or vice versa.  I do not see any problems using Interfaces where it makes sense.  

 

I remember situations where the development manager demanded that all methods are private except the few that the client is supposed to use.  That demand together with the dislike of Interfaces then asked for usage of JUnit extensions like Junitx (I think that is the name) which allow to test private methods (or to write my own reflection method retrieval for testing the privats).  Using Interfaces in that case would have improved the whole situation.

 

Andreas

 

 

________________________________

From: junit@... [mailto:junit@...] On Behalf Of Elliotte Harold
Sent: Wednesday, August 16, 2006 7:59 AM
To: junit@...
Subject: Re: [junit] Test-friendly, but not caller-friendly?

 

Andreas Guther wrote:
> There is always the possibility to define your API with Interfaces and thus have it as user friendly as possible without exposing any additional methods that were written in the actual implementation for the purpose of testing the class.
>

YUCK! That's like making your tech support user friendly by outsourcing
it to trained professionasl in India rather than letting your clients
talk directly to the developers. There's a ton of theory (i.e.
rationalizations) to support doing that, and it's completely
counterproductive in practice.

Interfaces are very popular among the most theoretical programmers: i.e.
exactly the sort of programmers who are likely to write books, read
books about OO theory, and hang out on lists like this one. However in
my experience concrete classes are much simpler and much preferred by
the vast majority of pragmatic programmers just getting their jobs done.

I can certainly see how making a class test-friendly could make it less
caller-friendly. In fact, exactly how to do that is the subject of
another perma-thread on this list. exposing methods purely for the
convenience of testers expands a class's interface and makes it harder
to learn, use, and understand. Minimal interfaces are simpler to
understand and learn. Exposing additional methods purely for test
convenience is very counter-productive to caller-convenience. The only
public parts of a class's interface should be things that are relevant
to client programmers.

--
Elliotte Rusty Harold elharo@... <mailto:elharo%40metalab.unc.edu>
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/ <http://www.cafeaulait.org/books/javaio2/>
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ <http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/>

 



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






 
Yahoo! Groups Links

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

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

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

[Cédric Beust ♔]

On 8/16/06, Elliotte Harold <elharo@...> wrote:

>
> Andreas Guther wrote:
> > There is always the possibility to define your API with Interfaces and
> thus have it as user friendly as possible without exposing any additional
> methods that were written in the actual implementation for the purpose of
> testing the class.
> >
>
> YUCK! That's like making your tech support user friendly by outsourcing
> it to trained professionasl in India rather than letting your clients
> talk directly to the developers. There's a ton of theory (i.e.
> rationalizations) to support doing that, and it's completely
> counterproductive in practice.
>
> Interfaces are very popular among the most theoretical programmers: i.e.
> exactly the sort of programmers who are likely to write books, read
> books about OO theory, and hang out on lists like this one. However in
> my experience concrete classes are much simpler and much preferred by
> the vast majority of pragmatic programmers just getting their jobs done.

This goes against my direct experience and against the widely accepted
recommendations that have emerged in the Java world these past years.

Interfaces are good. You shouldn't abuse them, of course, but they
contribute greatly to simplifying the contract between two parties.
Interfaces are also the foundation of very successful software platforms,
such as COM, Eclipse and Spring.

But your reaction proves the point I was making earlier even better than I
could have:  where do you draw the line when you are trying to "do the
simplest thing that could possibly work"?

In my experience, interfaces are very often part of this "simplest thing" as
long as they benefit both your tests and your users.

--
Cédric
http://testng.org


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



 
Yahoo! Groups Links

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

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

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

[Elliotte Harold]

Cédric Beust ♔ wrote:

> This goes against my direct experience and against the widely accepted
> recommendations that have emerged in the Java world these past years.

If I recall, your most recent direct experience is at Google, and given
the people Google is hiring these days, I'm not surprised that's what
you see. Google's a hotbed of the sort of programmers who like to read
and write books about OO theory and language design. But most of the
world is not Google.

There are certainly widely promulgated recommendations to use
interfaces. I'm not sure these recommendations are actually accepted by
anyone except the people promulgating them, though. In particular, what
I see is a lot of relatively smart people quietly blaming themselves for
not understanding the complexity that's being foisted on them, and
thinking they must be stupid for not understanding it. They may use
interfaces when forced to do so by the frameworks, but they don't like
it; and they certainly don't make it the first choice in their own code.

Interfaces have their place, but that place has been vastly overdrawn in
the Java world. Most classes simply do not need more than one
implementation.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

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

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

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

[Michael Feathers]

Elliotte Harold wrote:

>Andreas Guther wrote:
>  
>
>>There is always the possibility to define your API with Interfaces and thus have it as user friendly as possible without exposing any additional methods that were written in the actual implementation for the purpose of testing the class.
>>
>>    
>>
>
>YUCK! That's like making your tech support user friendly by outsourcing
>it to trained professionasl in India rather than letting your clients
>talk directly to the developers. There's a ton of theory (i.e.
>rationalizations) to support doing that, and it's completely
>counterproductive in practice.
>
>Interfaces are very popular among the most theoretical programmers: i.e.
>exactly the sort of programmers who are likely to write books, read
>books about OO theory, and hang out on lists like this one. However in
>my experience concrete classes are much simpler and much preferred by
>the vast majority of pragmatic programmers just getting their jobs done.
>  
>

Unfortunately, programmers who want to unit test their code suffer.  API
designers rarely think about testability of client code.  I see the
effect nearly every week at client sites.

Michael Feathers
www.objectmentor.com





 
Yahoo! Groups Links

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

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

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

[yollsonlegrand]

Can I be move from the list please? Thanks for your attention about this.
 
Ne rien dire pour nuire ,ne pas se taire pour plaire
Empereur Yollson
Lessingstr 43
76135 Karlsruhe

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





 
Yahoo! Groups Links

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

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

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

[yollsonlegrand]

Hi may i move my adress from the list please
 
Ne rien dire pour nuire ,ne pas se taire pour plaire
Empereur Yollson
Lessingstr 43
76135 Karlsruhe

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






 
Yahoo! Groups Links

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

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

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

[Michael Feathers]

Elliotte Harold wrote:

>Cédric Beust ♔ wrote:
>
>  
>
>>This goes against my direct experience and against the widely accepted
>>recommendations that have emerged in the Java world these past years.
>>    
>>
>
>If I recall, your most recent direct experience is at Google, and given
>the people Google is hiring these days, I'm not surprised that's what
>you see. Google's a hotbed of the sort of programmers who like to read
>and write books about OO theory and language design. But most of the
>world is not Google.
>
>There are certainly widely promulgated recommendations to use
>interfaces. I'm not sure these recommendations are actually accepted by
>anyone except the people promulgating them, though. In particular, what
>I see is a lot of relatively smart people quietly blaming themselves for
>not understanding the complexity that's being foisted on them, and
>thinking they must be stupid for not understanding it. They may use
>interfaces when forced to do so by the frameworks, but they don't like
>it; and they certainly don't make it the first choice in their own code.
>
>Interfaces have their place, but that place has been vastly overdrawn in
>the Java world. Most classes simply do not need more than one
>implementation.
>
>  
>

Unless you're testing.




 
Yahoo! Groups Links

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

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

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

[Timothy Wall-3]

On Aug 17, 2006, at 6:09 AM, Elliotte Harold wrote:

>
> Interfaces have their place, but that place has been vastly  
> overdrawn in
> the Java world. Most classes simply do not need more than one
> implementation.

And in the context of this discussion, making an interface around  
that class *only* helps testing that for whatever reason doesn't want  
to use that one implementation.

The public methods of a class define an interface implicitly, whether  
or not it is an explicit "java" interface.  Replacing with an  
"official" interface is a workaround to deficiencies in the language  
design rather than a "good practice" vis-a-vis defining the interface  
via public methods.




 
Yahoo! Groups Links

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

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

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

[Brett L. Schuchert]

Elliotte,
 
I don't work for Google and I love to use interfaces. In fact, I've been consulting at Hertz for 4 years. In that time we have rewritten most of their reservations systems from COBOL to Java AND retrained a majority of their COBOL programmers to use Java.
 
And guess what? We use interfaces. You know what else we use:
- Spring
- Hibernate
- JUnit (our base reference architecture has roughly 2900 unit tests and raising)
- AspectJ
- Continuous Integration
- ...
 
So here's a bunch (right now about 60 people working on roughly 6 active projects, with 9 projects already in production and being used in the field) of former COBOL programmers using interfaces, JUnit, Inversion of Control, all those "pie in the sky book things".
 
I do agree with some of what you are saying. Not everything should have an interface. But that's based on the granularity of the thing in question.
 
I also think, for the most part, that writing unit tests for a trivial Java Bean is questionable.
 
However, as soon as you start using things like Spring, using interfaces buys you a bunch. You can, for example, get automatic transactional demarcation based on a simple configuration. You can accomplish this without using interfaces (so long as the class is not also final), but it's a matter of whether you want to use proxies or classes generated using CGLIB.
 
Anything that I might want to test that depends on some external source of information (database, message queue, ...), using an interface (which you're probably doing anyway) really makes something testable in isolation. And it adds a lot of value.
 
That's NOT pie in the sky, that's based on actual experience in the field working with developers of vastly varying skills.
 
Tutorials and Articles
     http://schuchert.wikispaces.com/



----- Original Message ----
From: Elliotte Harold <elharo@...>
To: junit@...
Sent: Thursday, August 17, 2006 5:09:45 AM
Subject: Re: [junit] Test-friendly, but not caller-friendly?

Cédric Beust ♔ wrote:

> This goes against my direct experience and against the widely accepted
> recommendations that have emerged in the Java world these past years.

If I recall, your most recent direct experience is at Google, and given
the people Google is hiring these days, I'm not surprised that's what
you see. Google's a hotbed of the sort of programmers who like to read
and write books about OO theory and language design. But most of the
world is not Google.

There are certainly widely promulgated recommendations to use
interfaces. I'm not sure these recommendations are actually accepted by
anyone except the people promulgating them, though. In particular, what
I see is a lot of relatively smart people quietly blaming themselves for
not understanding the complexity that's being foisted on them, and
thinking they must be stupid for not understanding it. They may use
interfaces when forced to do so by the frameworks, but they don't like
it; and they certainly don't make it the first choice in their own code.

Interfaces have their place, but that place has been vastly overdrawn in
the Java world. Most classes simply do not need more than one
implementation.

--
Elliotte Rusty Harold elharo@metalab. unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaula it.org/books/ javaio2/
http://www.amazon. com/exec/ obidos/ISBN= 0596527500/ ref=nosim/ cafeaulaitA/

 

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





 
Yahoo! Groups Links

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

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

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

[unclebob]

> Sure, how about a Java ME application?

I visited Ward Cunningham a few years ago.  He took me to his  
basement and showed me a cute little DSP chip that he had programmed  
in assembler to draw concentric circles on a TV screen.  The program  
simply manipulated a D/A converter to generate the video signal.  Cute.

Then he said, "Now, how would you do this using TDD?"  He proceeded  
to show me a java program, complete with tests, that simulated the  
generation of the video signal, complete with the concentric  
circles.  The program he wrote was, in a way, a DSP simulator.  But  
it was more than that.  In essence he created an array of objects  
that correlated roughly to DSP instructions.  Each of these objects  
had two derivatives.  One mimicked the behavior of the DSP  
instruction that it represented, and the other emitted corresponding  
DSP assembly language to an output file.

The result was a very detailed DSP application, on a chip that did  
not support a high level language, written in Java using TDD.

Where there is a will, there is a way.

----
Robert C. Martin (Uncle Bob)  | email: unclebob@...
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |






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



 
Yahoo! Groups Links

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

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

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