Are you really using JUnit during your development?

[Michael Feathers]

Elliotte Harold wrote:

>Michael Feathers wrote:
>
>  
>
>>But back to your original point: "It might sometimes be a
>>NullPointerException or something else instead, but advertising a
>>precondition is not an excuse for misbehavior just because you receive
>>bad data." Under DbC, it is.  Fact is, if your precondition fails or you
>>get a NullPointerException, there's a bug in the client.  You can have
>>checking enabled, or not, but checking is not error handling.
>>    
>>
>
>Then maybe we agree more than we think. If checking is not error
>handling, then I accept that we don't need to handle the error. Indeed,
>in many cases we can't reasonably handle the error inside the method.
>However, I do think that it's important not to blindly accept a bad
>argument that violates a precondition and precede blindly ahead whatever
>happens. It is important to fail fast (and in a controlled and
>documented way via an exception) rather than let the software corrupt
>itself. Martin Fowler has written extensively about this:
>
>http://www.martinfowler.com/ieeeSoftware/failFast.pdf
>  
>

The thing that makes conversations like this so hard is that fact that
the context is often left hanging.  It's particularly bad when talking
about error handling and recovery because there is no one right approach
there.  Some systems have to be up all of the time and fail fast
wouldn't fly.  Jim outlines a great strategy in that article for the
cases where it's appropriate.

>>The point
>>of DbC is to build software robust enough so that you don't have to
>>write error handling code at each level.  Relevant section is 11.6
>>"Assertions are not an input checking mechanism."
>>    
>>
>
>That's something very different. Meyer clearly means *user* input in
>that section, and I agree with him on that. Assertions very much are an
>argument/parameter checking mechanism. I don't think we're talking here
>about user input, just about how two different methods from two
>different code bases communicate.
>  
>

Yes, I should have said more.  The thing I wanted to point out in that
section was that when you have checking that will lead you to do
something, it should be at the edges (what Meyer calls 'filter classes')
and not scattered throughout the code.  Otherwise, you are back at
defensive coding again.

>  
>
>>And when you say "It is my job to make sure my code works. I can't do
>>that if the code that calls it violates my preconditions and class
>>invariants."  Most of the time, that's trying to do too much.
>>    
>>
>
>
>Agreed. What I really should have said is something like, "It's my job
>to make sure my code works, or signals an error at the earliest possible
>opportunity if it can't work due to precondition violation"
>  
>

I think that, again, that is situational and it depends on your
development style.  I write a lot of tests for my code and when I work
with teams we often get to the point that they serve as primary
documentation.  If you want to see how something works, look a  test
case, if you can't find one, write one to make sure it works the way you
want to.  It's hard to describe what happens when you do that, but I
think the easiest thing is to say is that you are less concerned with
the correctness of a class, and more concerned with the correctness of
its use.  That may sound bad, but it works because your class becomes
the intersection of its uses.

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/
 

[Elliotte Harold]

Michael Feathers wrote:

> The thing that makes conversations like this so hard is that fact that
> the context is often left hanging.  It's particularly bad when talking
> about error handling and recovery because there is no one right approach
> there.  Some systems have to be up all of the time and fail fast
> wouldn't fly.  Jim outlines a great strategy in that article for the
> cases where it's appropriate.

That doesn't really change anything. If you can't even afford to throw
an exception, then you certainly can't afford to allow
precondition-violating arguments, and then let the system do whatever
random thing it happens to do. Precondition verification is more
important in systems that have to be up all the time, not less. Maybe
there are systems in which you silently reject the bad arguments, or log
an error message rather than throwing an exception. However no way
should you let bad data into such a critical system and just throw up
your hands and say you're not responsible for what happens when a client
violates your precondition.

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

We've gone on for a while in this thread, but I think if I had to
summarize my position it would be this:  Sure enough, Java doesn't
support runtime monitoring of preconditions for interfaces, but although
runtime monitoring is fine, the real benefit of a precondition is to
explain what a caller shouldn't do.  We may find ourselves performing
checks at the edge of a system, say at the client interfaces, but I
don't find much value in precondition checking inside application code.  
I prefer to write my code so that usage is obvious and documented with
test cases.

One of the most awkward things about advice in this area is that most of
the people offering advice have an API developer's bias.  They tend to
assume the stance (probably out of habit) that you don't know the
callers of your code, and that you have to assume the worst.  Not all
classes are APIs, and in fact, I'd go further and say that not all
public classes are APIs either.  Application developers can play by
different rules, and often they do.  I've worked with many teams who use
interfaces prolifically inside their applications, and they don't see
lack of preconditions as a problem because they have a shared
understanding, as a team, about what the interface is there to support.

Michael Feathers
www.objectmentor.com



Michael Feathers wrote:

>Elliotte Harold wrote:
>
>  
>
>>Michael Feathers wrote:
>>
>>
>>
>>    
>>
>>>But back to your original point: "It might sometimes be a
>>>NullPointerException or something else instead, but advertising a
>>>precondition is not an excuse for misbehavior just because you receive
>>>bad data." Under DbC, it is.  Fact is, if your precondition fails or you
>>>get a NullPointerException, there's a bug in the client.  You can have
>>>checking enabled, or not, but checking is not error handling.
>>>  
>>>
>>>      
>>>
>>Then maybe we agree more than we think. If checking is not error
>>handling, then I accept that we don't need to handle the error. Indeed,
>>in many cases we can't reasonably handle the error inside the method.
>>However, I do think that it's important not to blindly accept a bad
>>argument that violates a precondition and precede blindly ahead whatever
>>happens. It is important to fail fast (and in a controlled and
>>documented way via an exception) rather than let the software corrupt
>>itself. Martin Fowler has written extensively about this:
>>
>>http://www.martinfowler.com/ieeeSoftware/failFast.pdf
>>
>>
>>    
>>
>The thing that makes conversations like this so hard is that fact that
>the context is often left hanging.  It's particularly bad when talking
>about error handling and recovery because there is no one right approach
>there.  Some systems have to be up all of the time and fail fast
>wouldn't fly.  Jim outlines a great strategy in that article for the
>cases where it's appropriate.
>
>  
>
>>>The point
>>>of DbC is to build software robust enough so that you don't have to
>>>write error handling code at each level.  Relevant section is 11.6
>>>"Assertions are not an input checking mechanism."
>>>  
>>>
>>>      
>>>
>>That's something very different. Meyer clearly means *user* input in
>>that section, and I agree with him on that. Assertions very much are an
>>argument/parameter checking mechanism. I don't think we're talking here
>>about user input, just about how two different methods from two
>>different code bases communicate.
>>
>>
>>    
>>
>
>Yes, I should have said more.  The thing I wanted to point out in that
>section was that when you have checking that will lead you to do
>something, it should be at the edges (what Meyer calls 'filter classes')
>and not scattered throughout the code.  Otherwise, you are back at
>defensive coding again.
>
>  
>
>>
>>
>>    
>>
>>>And when you say "It is my job to make sure my code works. I can't do
>>>that if the code that calls it violates my preconditions and class
>>>invariants."  Most of the time, that's trying to do too much.
>>>  
>>>
>>>      
>>>
>>Agreed. What I really should have said is something like, "It's my job
>>to make sure my code works, or signals an error at the earliest possible
>>opportunity if it can't work due to precondition violation"
>>
>>
>>    
>>
>I think that, again, that is situational and it depends on your
>development style.  I write a lot of tests for my code and when I work
>with teams we often get to the point that they serve as primary
>documentation.  If you want to see how something works, look a  test
>case, if you can't find one, write one to make sure it works the way you
>want to.  It's hard to describe what happens when you do that, but I
>think the easiest thing is to say is that you are less concerned with
>the correctness of a class, and more concerned with the correctness of
>its use.  That may sound bad, but it works because your class becomes
>the intersection of its uses.
>
>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/
 

[Cédric Beust ♔]

On 9/4/06, Elliotte Harold <elharo@...> wrote:

>
>
> Yes, I do have a copy. I suspect you're referring to p. 343-344. However
> you have to remember that Meyer is writing about a language in which
> preconditions can be specified *and enforced* outside the body of the
> method. Since Java, unlike Eiffel, does not provide extra-method
> preconditions it is therefore necessary to place the verification code
> in the method body. It's not ideal, but Java is not an ideal language.
>
> Furthermore, for most cases, Meyer recommends precondition verification
> by default. See pp. 394-398

I am really not convinced that Meyer's approach, and Design by Contract in
general, is really relevant to the real world.  I blogged about it a few
years ago here <http://www.jroller.com/page/cbeust/20021213>, and my
conclusion was that preconditions, post-conditions and invariants were
usually either one of these:

   - Super simple, and better put in an assert.
   - Super complex, and better left to testing.

I also noticed that most of the methods that I write simply don't have any
invariant that can be easily expressed, so I have yet to see a convincing
example of Design by Contract on a project of more than a few thousands of
lines...  (incidentally, most of the Eiffel code that I worked with and read
was pretty bad and wouldn't pass today's standards).

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

[Michael Feathers]

Elliotte Harold wrote:

>Michael Feathers wrote:
>
>  
>
>>The thing that makes conversations like this so hard is that fact that
>>the context is often left hanging.  It's particularly bad when talking
>>about error handling and recovery because there is no one right approach
>>there.  Some systems have to be up all of the time and fail fast
>>wouldn't fly.  Jim outlines a great strategy in that article for the
>>cases where it's appropriate.
>>    
>>
>
>That doesn't really change anything. If you can't even afford to throw
>an exception, then you certainly can't afford to allow
>precondition-violating arguments, and then let the system do whatever
>random thing it happens to do. Precondition verification is more
>important in systems that have to be up all the time, not less. Maybe
>there are systems in which you silently reject the bad arguments, or log
>an error message rather than throwing an exception. However no way
>should you let bad data into such a critical system and just throw up
>your hands and say you're not responsible for what happens when a client
>violates your precondition.
>
>  
>

It changes your approach to design.  You do what you can to actively
minimize and eliminate preconditions; you end up patching things up and
producing special case objects.  Actually, it looks less like
precondition checking and more like designing alternative courses.

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/
 

[Elliotte Harold]

Michael Feathers wrote:

> Elliotte,
>
> We've gone on for a while in this thread, but I think if I had to
> summarize my position it would be this:  Sure enough, Java doesn't
> support runtime monitoring of preconditions for interfaces, but although
> runtime monitoring is fine, the real benefit of a precondition is to
> explain what a caller shouldn't do.  We may find ourselves performing
> checks at the edge of a system, say at the client interfaces, but I
> don't find much value in precondition checking inside application code.  
> I prefer to write my code so that usage is obvious and documented with
> test cases.
>

The boundary I would pick is the public API. If a method is public (or
protected) then there's really nothing you can do about who calls it and
nothing you can assume about what they will pass beyond the types of the
arguments. Internal classes not meant for public consumption need not
rigorously verify each precondition if substantial testing demonstrates
their correctness *provided* that they are not public. If they are
public, all bets are off.

Far too much code in Java is made public without adequate foresight.
Again this is partially a defect of the language since packages are
effectively private to each other. Following this principle usually
means you restrict yourself to a single package. It would be nice if
Java had a little more flexibility here, and we may indeed get that in
Java 7. Until then, though, non-verified classes should be non-public
and usually all in a single package.

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

[Elliotte Harold]

Cédric Beust ♔ wrote:

>
> I am really not convinced that Meyer's approach, and Design by Contract in
> general, is really relevant to the real world.  I blogged about it a few
> years ago here <http://www.jroller.com/page/cbeust/20021213>, and my
> conclusion was that preconditions, post-conditions and invariants were
> usually either one of these:
>
>    - Super simple, and better put in an assert.
>    - Super complex, and better left to testing.
>
> I also noticed that most of the methods that I write simply don't have any
> invariant that can be easily expressed, so I have yet to see a convincing
> example of Design by Contract on a project of more than a few thousands of
> lines...  

I'm not sure exactly how many lines it is, but XOM might qualify.

I don't see a real conflict between testing and DBC. I use them both.
Testing makes sure my code is correct. DBC makes sure other people's
code that invokes my code doesn't cause problems. They're really
addressing two different concerns.

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

[James Abley]

On 23/08/06, J. B. Rainsberger <jbrains@...> wrote:

>
>   Shane Mingins wrote:
>
> > (JB) Is the TDD list a good place to discuss the TDD aspects/challenges
> with
> > Rails??? I would be interested in following any discussions.
>
> Yes, except that I don't read that list, so I wanted the discussion to
> stay here for a while. I'm 9,362 messages behind on the TDD list.
>

You lucky thing. I'm around 500 _threads_ behind on the JUnit list
currently.


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


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

>Michael Feathers wrote:
>  
>
>>Elliotte,
>>
>>We've gone on for a while in this thread, but I think if I had to
>>summarize my position it would be this:  Sure enough, Java doesn't
>>support runtime monitoring of preconditions for interfaces, but although
>>runtime monitoring is fine, the real benefit of a precondition is to
>>explain what a caller shouldn't do.  We may find ourselves performing
>>checks at the edge of a system, say at the client interfaces, but I
>>don't find much value in precondition checking inside application code.  
>>I prefer to write my code so that usage is obvious and documented with
>>test cases.
>>
>>    
>>
>
>The boundary I would pick is the public API. If a method is public (or
>protected) then there's really nothing you can do about who calls it and
>nothing you can assume about what they will pass beyond the types of the
>arguments. Internal classes not meant for public consumption need not
>rigorously verify each precondition if substantial testing demonstrates
>their correctness *provided* that they are not public. If they are
>public, all bets are off.
>  
>

Let me ask you a question.. if you buy a stereo and the manufacturer
wants to make it clear that you're on your own when you muck with the
internals, do they seal the stereo so that it's completely inaccessible
or do they do something different?

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/
 

[Ray V-2]

I wonder what you guys think of Contract4J:
http://www.contract4j.org/contract4j

It combines an annotation based design by contract
approach with the "fail fast" philosophy, and can be
turned off (like assertions) when it's time to deploy.
 

It seems very complimentary to unit testing, and would
help in doing less defensive programming.  I've been
curious about this tool for a while, but have yet to
use it myself on a real project.

--- Cédric Beust ♔  <cbeust@...> wrote:

> On 9/4/06, Elliotte Harold <elharo@...>
> wrote:
> >
> >
> > Yes, I do have a copy. I suspect you're referring
> to p. 343-344. However
> > you have to remember that Meyer is writing about a
> language in which
> > preconditions can be specified *and enforced*
> outside the body of the
> > method. Since Java, unlike Eiffel, does not
> provide extra-method
> > preconditions it is therefore necessary to place
> the verification code
> > in the method body. It's not ideal, but Java is
> not an ideal language.
> >
> > Furthermore, for most cases, Meyer recommends
> precondition verification
> > by default. See pp. 394-398
>
>
> I am really not convinced that Meyer's approach, and
> Design by Contract in
> general, is really relevant to the real world.  I
> blogged about it a few
> years ago here
> <http://www.jroller.com/page/cbeust/20021213>, and
> my
> conclusion was that preconditions, post-conditions
> and invariants were
> usually either one of these:
>
>    - Super simple, and better put in an assert.
>    - Super complex, and better left to testing.
>
> I also noticed that most of the methods that I write
> simply don't have any
> invariant that can be easily expressed, so I have
> yet to see a convincing
> example of Design by Contract on a project of more
> than a few thousands of
> lines...  (incidentally, most of the Eiffel code
> that I worked with and read
> was pretty bad and wouldn't pass today's standards).
>
> --
> Cédric
> http://testng.org
>
>
> [Non-text portions of this message have been
> removed]
>
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.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/
 

[Michael Feathers]

Ray,

Contract4J was written by Dean Wampler, and he recently joined
objectmentor. We were talking about it the other week while we were
working together. I haven't had a chance to try it yet, but I think that
the notion of embedding a language inside annotations is very interesting.

Michael

Ray V wrote:

>I wonder what you guys think of Contract4J:
>http://www.contract4j.org/contract4j
>
>It combines an annotation based design by contract
>approach with the "fail fast" philosophy, and can be
>turned off (like assertions) when it's time to deploy.
>
>
>It seems very complimentary to unit testing, and would
>help in doing less defensive programming.  I've been
>curious about this tool for a while, but have yet to
>use it myself on a real project.
>
>--- Cédric Beust â™”  <cbeust@...> wrote:
>
>  
>
>>On 9/4/06, Elliotte Harold <elharo@...>
>>wrote:
>>    
>>
>>>Yes, I do have a copy. I suspect you're referring
>>>      
>>>
>>to p. 343-344. However
>>    
>>
>>>you have to remember that Meyer is writing about a
>>>      
>>>
>>language in which
>>    
>>
>>>preconditions can be specified *and enforced*
>>>      
>>>
>>outside the body of the
>>    
>>
>>>method. Since Java, unlike Eiffel, does not
>>>      
>>>
>>provide extra-method
>>    
>>
>>>preconditions it is therefore necessary to place
>>>      
>>>
>>the verification code
>>    
>>
>>>in the method body. It's not ideal, but Java is
>>>      
>>>
>>not an ideal language.
>>    
>>
>>>Furthermore, for most cases, Meyer recommends
>>>      
>>>
>>precondition verification
>>    
>>
>>>by default. See pp. 394-398
>>>      
>>>
>>I am really not convinced that Meyer's approach, and
>>Design by Contract in
>>general, is really relevant to the real world.  I
>>blogged about it a few
>>years ago here
>><http://www.jroller.com/page/cbeust/20021213>, and
>>my
>>conclusion was that preconditions, post-conditions
>>and invariants were
>>usually either one of these:
>>
>>   - Super simple, and better put in an assert.
>>   - Super complex, and better left to testing.
>>
>>I also noticed that most of the methods that I write
>>simply don't have any
>>invariant that can be easily expressed, so I have
>>yet to see a convincing
>>example of Design by Contract on a project of more
>>than a few thousands of
>>lines...  (incidentally, most of the Eiffel code
>>that I worked with and read
>>was pretty bad and wouldn't pass today's standards).
>>
>>--
>>Cédric
>>http://testng.org
>>
>>
>>[Non-text portions of this message have been
>>removed]
>>
>>
>>    
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around
>http://mail.yahoo.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/
 

[Cédric Beust ♔]

On 9/4/06, Ray V <ttftestrayv@...> wrote:

>
> I wonder what you guys think of Contract4J:
> http://www.contract4j.org/contract4j
>
> It combines an annotation based design by contract
> approach with the "fail fast" philosophy, and can be
> turned off (like assertions) when it's time to deploy.
>
>
> It seems very complimentary to unit testing, and would
> help in doing less defensive programming.  I've been
> curious about this tool for a while, but have yet to
> use it myself on a real project.

Based on the example on the Web site, it seems to me it's the wrong way to
solve the problem.

The example is basically moving asserts inside the method into a string
inside an annotation.  By doing that, you lose type checking, you lose IDE
assistance, you lose highlighting and you lose refactoring capabilities.

I also wonder how well it scales when your preconditions or postconditions
need to span ten lines, or when you want to intersperse them in-between
several lines inside your method.

These reasons are exactly why I think Design by Contract simply doesn't
work:  either your DBC tests are small enough to fit in one-line assertions
(which can be optimized away by the compiler) or they are fairly complex and
better captured in tests.

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

[Cédric Beust ♔]

One more thought:  I don't think AOP is the right tool for this job.

AOP helps you when the same concerns are crosscutting your code and can be
factored out.  In the case of pre/postconditions or invariants, each of
these will be fairly unique to the method they apply to, so there is little
reuse going on, and therefore, little point in capturing them in aspects
(which this tool doesn't seem to do, by the way, since they are captured in
a string).

--
Cedric


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

>
>
>
> On 9/4/06, Ray V <ttftestrayv@...> wrote:
> >
> > I wonder what you guys think of Contract4J:
> > http://www.contract4j.org/contract4j<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.contract4j.org%2Fcontract4j>
> >
> > It combines an annotation based design by contract
> > approach with the "fail fast" philosophy, and can be
> > turned off (like assertions) when it's time to deploy.
> >
> >
> > It seems very complimentary to unit testing, and would
> > help in doing less defensive programming.  I've been
> > curious about this tool for a while, but have yet to
> > use it myself on a real project.
>
>
> Based on the example on the Web site, it seems to me it's the wrong way to
> solve the problem.
>
> The example is basically moving asserts inside the method into a string
> inside an annotation.  By doing that, you lose type checking, you lose IDE
> assistance, you lose highlighting and you lose refactoring capabilities.
>
> I also wonder how well it scales when your preconditions or postconditions
> need to span ten lines, or when you want to intersperse them in-between
> several lines inside your method.
>
> These reasons are exactly why I think Design by Contract simply doesn't
> work:  either your DBC tests are small enough to fit in one-line assertions
> (which can be optimized away by the compiler) or they are fairly complex and
> better captured in tests.
>
> --
> Cédric
> http://testng.org<http://www.google.com/url?sa=D&q=http%3A%2F%2Ftestng.org>
>
>

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

[Elliotte Harold]

Cédric Beust ♔ wrote:

> These reasons are exactly why I think Design by Contract simply doesn't
> work:  either your DBC tests are small enough to fit in one-line assertions
> (which can be optimized away by the compiler) or they are fairly complex and
> better captured in tests.

Let me say it again: tests are not a substitute for DBC, and DBC is not
a substitute for tests. They are two different techniques, and you need
both.

Tests are written by the provider to verify that the *provider*'s code
is correct. DBC is written by the provider to verify that the *client*'s
code is correct. This is a critical distinction. The provider can rely
on their own tests, but they cannot rely on the clients'.

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

>Cédric Beust ♔ wrote:
>
>  
>
>>These reasons are exactly why I think Design by Contract simply doesn't
>>work:  either your DBC tests are small enough to fit in one-line assertions
>>(which can be optimized away by the compiler) or they are fairly complex and
>>better captured in tests.
>>    
>>
>
>Let me say it again: tests are not a substitute for DBC, and DBC is not
>a substitute for tests. They are two different techniques, and you need
>both.
>
>Tests are written by the provider to verify that the *provider*'s code
>is correct. DBC is written by the provider to verify that the *client*'s
>code is correct. This is a critical distinction. The provider can rely
>on their own tests, but they cannot rely on the clients'.
>  
>

I think the line is fuzzier than that.  Postconditions don't verify the
client.

To me, the difference is like the difference between an endoskeleton
(checked DbC) and an exoskeleton (UTs).  Both provide support for motion
in different ways.

The sneaky thing about DbC is that if you want to use its assertions
essentially as tests you have to exercise your code.  It's not just a
matter of writing the assertions.  When you test, the code that you
write is the exercising code, and you can test both clients and
providers.  Not saying that DbC is bad, just that I wouldn't want to
rely on its assertion mechanism rather than tests.  On the other hand, I
feel oddly comfortable writing code with lots of tests and no embedded
DbC constructs.

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/
 

[unclebob]

> That's not what I was saying. If you use the Interface Segregation
> Principle, you can't pass an IAccount2 to someone expecting an  
> IAccount.
>
> Which makes this principle fairly useless in my opinion...

You can, if the object you are passing derives from both IAccount and  
IAccount2...

interface IAccount {...}
interface IAccount2 {...}
public class MyAccount implements IAccount, IAccount2 {...}

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

MyAccount ma = new MyAccount(...);
f(ma);
g(ma);

public void h(IAccount a) {
   g((IAccount2)a);
}


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

[Cédric Beust ♔]

On 9/4/06, Robert Martin <UncleBob@...> wrote:

>
>
> > That's not what I was saying. If you use the Interface Segregation
> > Principle, you can't pass an IAccount2 to someone expecting an
> > IAccount.
> >
> > Which makes this principle fairly useless in my opinion...
>
> You can, if the object you are passing derives from both IAccount and
> IAccount2...

Sure, but the client code won't be able to do that since it was written
before IAccount2 was released.

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

[unclebob]

> Robert Martin wrote:
>
> > It's not. Overuse of factories is an abomination. So *IF* I thought
> > an interface would help, I would simply prefer:
> >
> > Document doc = Document.newDocument();
>
> But you can't do that with an interface. At a minimum you need
>
> Document doc = Factory.newDocument();

Sorry, sometimes I forget about Java's dumb rules about where you can  
have static methods and where you can't.  Anyway, this works in Java  
and amounts to the same thing:

interface Document extends Cloneable {
   public static Document prototype = null;
   ...
}

Document doc = Document.prototype.clone();

Make sure "main" sets the Document.prototype variable to the  
prototypical Document derivative.

>
> > The simplicity of interfaces vs concrete classes comes from
> > dependencies. Let's say we have some concrete class named
> > MyDocument, and it has lots and lots of methods. Users of this class
> > depend on all these methods even if they don't call them. If I make
> > a change to MyDocument it can affect all the callers to the extent
> > that they all have to be recompiled and redeployed. (Yes, you can
> > play the game and try to figure out whether or not the class really
> > and truly needs to be recompiled, but that way lay madness.)
>
> In Java, if the public interface of the class doesn't change, you  
> don;t
> need to recompile clients. In fact, even if you only add things to the
> public interface of the class, you don't need to recompile clients.

Not quite true.  It is possible to add a method to the public  
interface of a java class that makes previous calls to similar  
methods ambiguous.   For example:

public class Y {
   public static void main(String[] args) {
     X x = new X();
     x.f(1);
   }
}

public class X {
   public void f(double d) {
     System.out.println("d = " + d);
   }

//  public void f(int i) {
//    System.out.println("i = " + i);
//  }
}

Adding the second f function without recompiling Y can lead to the  
wrong function being called.

> In
> fact, you only need to recompile clients if the public interface  
> changes
> in such a way that the clients need to be rewritten.

True, except when it isn't.  Anyway, like I said, you can play the  
game that way if you like; but it's not foolproof.  Anyway, most IDEs  
and build systems are pretty aggressive about recompiling if they  
think something might have changed.  This can make it difficult to  
play the game.

>
> > If I interpose one or more interfaces then suddenly the callers
> > depend ONLY on the methods in the interfaces that they use; and  
> those
> > interfaces can be *very* sparse.
>
> If I have a class that depends on only two methods in the library  
> class,
> then any changes beyond those two methods and the class signature  
> itself
> are irrelevant to the client, and do not require recompilation. You do
> not need to interpose an interface to get this benefit. Dynamic  
> binding
> gives this to you automatically.

That's the theory.  In a language like Ruby it works 100% of the  
time.  In a language like Java it works 99% of the time.

> Now in a language like C++ that links
> statically, it may be a very different story. But in Java the clients
> depend only on the methods in the class that they actually use. A  
> public
> change to a method the client actually uses requires rewriting and
> recompilation, but so does a change to such a method in an interface.
> Interfaces add nothing to this.
>
> > Even if there is only one
> > interface, and that interface has all the methods of MyDocument I  
> can
> > still swap out MyDocument for some other implementation or some Mock
> > implementation. I can also add new methods to MyDocument without
> > forcing recompilation and redeployment of the callers.
>
> Again, if MyDocument is a class you can still add new methods to
> MyDocument without forcing recompilation and redeployment of the
> callers. This has nothing to do with interfaces and everything to do
> with dynamic linking. (And again, I'm talking about Java here. It  
> can be
> different in other languages.)

Let me put it to you another way.  Module A depends on Module B, but  
only if you call the A.f method.  I ship you a new version of Module  
A but I don't give you the latest module B because you don't call the  
f method.  Are you happy?  Or are you going to ask me for module B  
anyway, just in case...?  Or would you rather I give you an interface  
for Module A that does not have the f method?


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

[unclebob]

> It is my job to make sure my code works. I can't do that if the code
> that calls it violates my preconditions and class invariants.

So check for those preconditions and invariants if you must.  And  
then write unit tests that make sure your code works as you expect,  
including that it detects the faulty preconditions and invariants.
----
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/
 

[Elliotte Harold]

Michael Feathers wrote:

> I think the line is fuzzier than that.  Postconditions don't verify the
> client.
>

True. That's why I agree with Meyer that postconditions do not need to
be checked at runtime, and can be replaced by tests. Meyer's quite clear
that postconditions and preconditions are quite different things. A
precondition failure is a client bug. A postcondition failure is a
provider bug. Provider bugs can be addressed by provider testing. Client
  bugs cannot be.

Class invariants, I suppose, can fall in either camp. If the class
maintains its invariants provided all preconditions are satisfied, then
it doesn't need to be verified except through testing. However, if
method invocations that satisfy individual preconditions can together
violate the class invariant, then you'd need to check the invariant at
runtime. For example, imagine a Money class with both a setDollars and a
setCents method. Both dollars and cents can be negative, zero, or
positive. However, if one is negative the other must be nonPositive and
if one is positive, the other must be nonNegative. There the invariant
crosses the boundaries between the methods. I prefer to avoid this if
possible, but sometimes it happens.


> The sneaky thing about DbC is that if you want to use its assertions
> essentially as tests you have to exercise your code.  It's not just a
> matter of writing the assertions.  When you test, the code that you
> write is the exercising code, and you can test both clients and
> providers.  Not saying that DbC is bad, just that I wouldn't want to
> rely on its assertion mechanism rather than tests.  

One of the things I write unit tests for is the proper behavior of the
methods in the face of a precondition violation. (Usually that's
throwing an exception.)

> On the other hand, I
> feel oddly comfortable writing code with lots of tests and no embedded
> DbC constructs.

You're perhaps not worrying about other programmers using your code with
no tests, or other programmers trying to break your security and do bad
things with your code. I am quite uncomfortable thinking about such
things. That's why I check my preconditions rigorously.

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