Are you really using JUnit during your development?

[Elliotte Harold]

Michael Feathers wrote:

> Not exactly user-centered design, is it?

It exactly is user-centered design. The users get what they need. That
the users don't always know what they need, or want things that are
actively harmful to their interests, is an education issue; and one that
is addressed by refusing to give them what they want, and then
explaining why they don't really want that when the questions come in.

--
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 Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/WktRrD/lOaOAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~->

 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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]

> Robert Martin wrote:
>
> > A simple constructor is the easiest. However, as the system starts
> > to get complicated those simple constructors sometimes become
> > complications because of the need to have mocks for unit tests.  
> Later
> > they become even greater complications because of the need to break
> > or invert dependencies between modules.
>
> At such point as that becomes a real problem, I'm willing to  
> refactor to
> accomplish this. However in my experience most classes are not reused,
> most do not need to be mocked, most do not need to be decoupled, and
> very few classes need multiple implementations.

Agreed on all points except, possibly, the definition of the term  
"most".  If by that you mean "more than half" then I agree.  If, on  
the other hand you mean "the overwhelming majority" then I don't.  In  
my experience quite a few classes wind up needing this kind of  
decoupling.
> My objection is not to using these techniques in the rare cases where
> it's actually necessary.

Rare?

> My objection is to starting by assuming that
> the simplest thing (concrete classes with constructors) can't possibly
> work, and jumping straight into the deep end every time.

I agree with that.  I find, however, that I *do* move many of them to  
interfaces in short order.

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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]

> It seems we're talking past each other...
>
> I have a client that uses IAccount.

public class me {
   public static void f(IAccount a) {...}
}

> I release an extension of IAccount
> called IAccount2, that has a few extra methods,

interface IAccount2 {
   public void g();
}

> but I want to be able to
> pass these IAccount2 objects to clients that expect IAccount,

class MyAccount implements IAccount, IAccount2 {...}

IAccount ia = new MyAccount();
me.f(ia);  // works just fine.

Now, if we want me.f to call g, then we have to change me.f anyway,  
so we might as well change it as follows:

public class me {
   public static void f(IAccount a) {
     ((IAccount2)a).g()
   }
}

> and the only
> way to do this is to have IAccount2 extend IAccount.

I think the above does it without having IAccount2 extend from IAccount.

>
> Which is why I was saying that since the Interface Segregation  
> Principle
> doesn't respect the is-a relationship, it's of little help for upgrade
> problems, and the technique that I described in my initial message  
> was the
> only viable way to add methods to existing interfaces without breaking
> clients.

There are quite a few ways to add methods to existing interfaces  
without breaking clients.  Visitor, Decorator, Extension Object, and  
ISP all manage to do that.


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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

> J. B. Rainsberger wrote:
>  > Elliotte Harold wrote:
>  >
>  >> http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161 
> <http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161>
>  >> <http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161 
> <http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161>>
>  >
>  > I tried, but there is plain text at the top of the file (before the
>  > preamble), so neither of my browsers will render it.
>
> Damn, I see what happened. Ant's putting warnings in the same file it
> where it places the output. I'll fix it. Try
>
> http://www.xom.nu/designprinciples.xhtml#d0e161 
> <http://www.xom.nu/designprinciples.xhtml#d0e161>

That worked. Thank you.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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/
 

[kentb]

All,
 
I just wrote the section on interfaces vs. superclasses in Implementation
Patterns, so I have some opinions. My analysis boils down to: interfaces
hide more details (potentially) but you can't add a method to an interface
without breaking client code the way you can with a superclass. In general I
prefer disciplined use of superclasses (no non-private members, judicious
use of protected methods) but interfaces are more common.
 
Cheers,
 
Kent Beck
Three Rivers Institute
Author of Implementation Patterns, due out in the fourth quarter of 2006


  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Cédric Beust ?
Sent: Friday, September 01, 2006 9:06 AM
To: junit@...
Subject: Re: [junit] Test-friendly, but not caller-friendly?



Hi Elliotte,

On 9/1/06, Elliotte Harold <elharo@metalab.
<mailto:elharo%40metalab.unc.edu> unc.edu> wrote:

>
> Michael Feathers wrote:
>
> > Elliotte, what are the downsides of interfaces, in your opinion? I know
> > you don't like to use them as much as many other people do, but I don't
> > know why.
>
> 1. Excess complexity
>
> 2. No precondition, postcondition, or class invariant validation
>
> 3. Cannot add new methods to an existing interface in a later version
> without breaking all existing code

Fair points.

Interfaces do add some complexity, but they also buy you flexibility and
extensibility, so I'd be sure to always weigh these different aspects before
choosing (or not) to introduce an interface.

I would argue that concrete classes suffer from 2) as well, and the only way
you can guarantee that the orchestration of your classes/interfaces is
respected is... with tests.

Indeed, interfaces should become immutable once they are published, but
there are ways to support interfaces with added methods without breaking
backward compatibility. Here is how.

Suppose you publish an interface:

public interface IAccount {
public void processCash();
}

In v2, you decide your account needs to support credit cards as well, so you
create the following interface:

public interface IAccount2 extends IAccount {
public void processCreditCard();
}

Now, your business code needs to use the following trick:

IAccount a = ...;

if (a instanceof IAccount2) {
IAccount2 a2 = (IAccount2) a;
a2.processCreditCard();
}

This code is guaranteed to be fully backward compatible and yet allow for
your interfaces to grow with your needs. This trick is used extensively in
COM and Eclipse, so while the instanceof is still a bit annoying, it's still
important to be aware of such a possibility.

--
Cédric
http://testng. <http://testng.org> 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/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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/
 

[Marvin D. Toll]

 

I'm not sure it was explicit in Kent's post . but the inability to use
"protected" methods with an Interface is an impediment to a robust
leveraging of inheritance.

 

It is a second differentiator: base (or super) classes support "protected"
methods - interfaces do not.

 

_Marvin

 

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

|  USA Cell: 248.866.4897 (free incoming)

|  Message:  <mailto:2488664897@...>
2488664897@...

|  Email:  <mailto:MarvinToll@...> MarvinToll@...

|  Web:  <http://www.gtcGroup.com> http://www.gtcGroup.com

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

 

 
<http://groups.yahoo.com/group/junit/message/17904;_ylc=X3oDMTJyZHRmb2dqBF9T
Azk3MzU5NzE1BGdycElkAzI0MjMzMjgEZ3Jwc3BJZAMxNjAwMDA2OTA1BG1zZ0lkAzE3OTA0BHNl
YwNkbXNnBHNsawN2bXNnBHN0aW1lAzExNTgxNjYwMDI-> Re: Test-friendly, but not
caller-friendly?

Posted by: "Kent Beck"
<mailto:kentb@...?Subject=%20Re%3A%20Test-friendly%2C%20but%20not%
20caller-friendly%3F> kentb@...
<http://profiles.yahoo.com/kentlbeck> kentlbeck

Tue Sep 12, 2006 9:51 am (PST)

All,

I just wrote the section on interfaces vs. superclasses in Implementation
Patterns, so I have some opinions. My analysis boils down to: interfaces
hide more details (potentially) but you can't add a method to an interface
without breaking client code the way you can with a superclass. In general I
prefer disciplined use of superclasses (no non-private members, judicious
use of protected methods) but interfaces are more common.

Cheers,

Kent Beck
Three Rivers Institute
Author of Implementation Patterns, due out in the fourth quarter of 2006

 



[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/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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/
 

[Stephen Smith-2]

I might be coming late to this particular thread, but whatever happened
to the rule of "use unchecked exceptions for developer error, use
checked exceptions for exceptional conditions"?
--
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/

J. B. Rainsberger wrote:

> Elliotte Harold wrote:
>> Checked exceptions get
>> programmers to write a lot more error handling code than documentation
>> ever did. (Not quite as much as they should, of course, but a lot more
>> than they used to.)
>
> ...a lot more, by percentage? I doubt it. For every person that handles
> checked exceptions, there are, I'm guessing, several (dozens?) that
> either simply wrap them in unchecked ones (fine with me) or do catch {}
> (oy). This pattern repeats, over and over.
>
> The programmers that /do/ write error handling code are the ones that
> would have done it before, if it had required less of an investment.
> Those are the same programmers who will write equals() and hashCode()
> correctly if they know that EqualsTester exists and how to use it. They
> don't need code enforcement; they can get by with useful tools.
>
> Take care.

 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:junit-digest@...
    mailto:junit-fullfeatured@...

<*> 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/