Are you really using JUnit during your development?

[unclebob]

> Sure, how about a Java ME application?

Of course a Java ME application IS a java application.  Much of the  
java code can be written and tested in a J2SE environment.  A willing  
designer could even create mockups of the ME environment sufficient  
to allow considerable test coverage in the host environment.

I have customers who complete the testing connection to their  
embedded devices by writing unit tests on the host environment that  
make calls over a USB connection to a simple little program on the  
device that then knows how to call into the embedded application.  
Think of it as a very poor man's RPC.

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

[unclebob]

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

I'm quite happy to stand by that claim.  Over the last 7 years I have  
come to the following conclusions:

1. There are no instances in which TDD is impossible.
2. There are no instances in which TDD is not advantageous.
3. The impediments to TDD are human, not technical.
4. The alternative to TDD is code that is not repeatably testable.

Therefore I consider TDD to be a minimum professional standard.  
Developers who do not use TDD fall below that standard.
>
> > 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.

I'm afraid I'm the counter example. I am nearly 54 years old and have  
been writing code since I was 15.  I still write code of one kind or  
another nearly every day.  I have worked on projects large and small,  
embedded and batch, system and application, in sickness and in heath,  
and I expect to code till I die.  Like Isaac Asimov used to say, I  
want them to find me with my nose jammed between the keys of my  
keyboard.

I'm afraid that there are also other counter examples.  I just got  
back from consulting with a team of 18 .NET developers working on a  
huge web-based application.  They have code coverage in the 90s, have  
unit tests and acceptance tests that are run every build.

Take a look at the Rails framework.  This is a web-development  
framework that has testing built in from the very start.  Virtually  
every facet of a rails application is intended to be written using  
TDD.  The point is that the new hyper-productive frameworks are  
adopting TDD from the get-go.

TDD is a fundamental change in the minute by minute process of  
writing software.  Many developers are not willing to face that  
change and look for reasons why TDD does not apply to them.  I  
believe that there are no such reasons.


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

Hi Elliotte,

On 8/17/06, Elliotte Harold <elharo@...> 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.

I have to say I'm quite amused to be characterized this way, but I'll gloss
over the personal stuff to get back to the debate.

As I mentioned earlier, Spring, Eclipse and a few other popular frameworks
in the Java world have shown that interfaces are not just a fad and that
their usefulness to solve real-world problems is solidly established, and
increasing every day.

Conversely, the exaggerated reliance on concrete classes has proven (again:
both in books and in the industry) to cause all sorts of code smells, among
which:  unnecessary coupling, difficulty to test, problematic maintenance,
reliance on undocumented behavior, etc...

On a more general level, it's quite interesting to see TDD advocates now
finding themselves in the difficult position of having to choose beween
"doing the simplest thing that could possibly work" (avoid interfaces, use
hard core concrete classes) and "write code that can be tested" (and
interfaces are usually recognized to help in that area).

I'll give a chance to other readers on this mailing-list to jump in and
state their thoughts on interfaces before digging deeper myself.

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

[Rob Sanheim]

On 8/17/06, Cédric Beust ♔ <cbeust@...> wrote:
[snip]

> As I mentioned earlier, Spring, Eclipse and a few other popular frameworks
> in the Java world have shown that interfaces are not just a fad and that
> their usefulness to solve real-world problems is solidly established, and
> increasing every day.
>
> Conversely, the exaggerated reliance on concrete classes has proven (again:
> both in books and in the industry) to cause all sorts of code smells, among
> which:  unnecessary coupling, difficulty to test, problematic maintenance,
> reliance on undocumented behavior, etc...
>
> On a more general level, it's quite interesting to see TDD advocates now
> finding themselves in the difficult position of having to choose beween
> "doing the simplest thing that could possibly work" (avoid interfaces, use
> hard core concrete classes) and "write code that can be tested" (and
> interfaces are usually recognized to help in that area).

I think you are setting up a false dichotomy here.

When I was working at a Spring/Hibernate shop, the "simplest thing"
depended entirely on context.  For example, when I would writing a
DAO, I would begin with a concrete class and basic tests, just to get
up and running.  This would usually not last long, as I found the
environment pushed me to develop in the idiomatic Spring way, by using
an interface and DI.  For a common case like a DAO, I found this
pattern recurring so often that I would often skip the concrete class
and go right to the interface with the real implementation and
test-friendly implementation.

Was this violating "simplest thing" ?  Even if we follow YAGNI or any
other agile mantra,  doesn't mean the experienced developer should
turn their brain off.  When you see the "simplest thing" in a specific
context get refactored into something more complex many times over, it
only makes sense to recognize that and go right to the more complex
case -- in that context.  Maybe the "simplest thing" was really too
simple, as it wasn't testable enough or flexible enough or it was
simply not consistent with the rest of the design.

On the other hand, even when I was in interface-happy JavaLand, many
times the simplest thing would prove to be just fine - particularly if
it was a simple utility class or some limited business model that
didn't need additional abstraction.

So its not a choice between interfaces and concrete, or writing the
simplest thing or the testable thing.  Its using your experience and
wisdom to decide what is best for the specific case and context - some
times that means starting with a concrete POJO, at other times it
means going right to an interface with some DI.  If its some brand new
situation or domain where you have very little experience, then you
can fall back on KISS or YAGNI or whatever practice helps you through
it, until you have the experience to see what really constitutes the
"simplest thing" to begin with.

- Rob
--
http://www.robsanheim.com
http://www.seekingalpha.com
http://www.ajaxian.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:

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


I disagree with that too. :-) I much prefer to test the actual classes
rather than mock classes. Doing so I often discover bugs that aren't at
all what I expected and that would have been missed by mock testing. The
thorniest bugs are often at the intersections between classes rather
than in the classes themselves.

Like interfaces, mocks have their place; but also like interfaces, that
place is often seen to be broader than it really is.


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

>Michael Feathers 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.
>>>
>>>
>>>
>>>      
>>>
>>Unless you're testing.
>>    
>>
>
>
>I disagree with that too. :-) I much prefer to test the actual classes
>rather than mock classes. Doing so I often discover bugs that aren't at
>all what I expected and that would have been missed by mock testing. The
>thorniest bugs are often at the intersections between classes rather
>than in the classes themselves.
>
>Like interfaces, mocks have their place; but also like interfaces, that
>place is often seen to be broader than it really is.
>  
>

I like the incidental coverage you get from using real classes also, but
there's a point past which you aren't doing unit testing any more;
you're just running large system tests in JUnit and they don't help you
isolate errors every well.

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/
 

[J. B. Rainsberger]

Cédric Beust ♔ wrote:

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

At your leisure.

> 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).

If it does, then that's often a sign of inappropriate mixture of levels
of abstraction.

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

See my previous comment.

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

OK. We need to agree to talk about "proper or good practice" or "common
practice". When we evaluate an idea, we need to decide whether we've
evaluating the fitness of the idea or the fitness of the idea for
popular use. Which is it? I tend to evaluate the fitness of the idea
first, then if it is fit, decide how it would be misused.

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

See my previous comment. No argument to the contrary.
--
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


 
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/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

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

I'm unsure about that analogy. If the trained professionals in India
provided the same experience as talking directly to programmers, then it
would be just fine. Obviously, that doesn't happen, but I can implement
an interface two different ways to provide experiences similar enough
that the client can't tell the difference. (Example: XStream object
storage compared to a relational database.)

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

I find it difficult not to interpret this as a (very mild) personal
attack. You seem to imply that we are not also practitioners. I suspect
you're not an asshole, so I imagine you mean something else. I would
appreciate you clarifying this position. Is it necessarily the case,
then, that "the sort of programmers who... hang out on lists like this
one" don't know what we're talking about, because I kinda think I do and
I kinda think I've proven that.

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

You're trivially right, in the sense that 39124 > 39123. Like anything
else, done badly, the result is bad; but done well, the result is just
fine. If I add a few methods just for testing, then that exposes a
missing abstraction, it's also likely that we can /simplify/ the design
by reducing the average cognitive load per class/interface/unit.

I would love the opportunity to pair with you to see what you do
differently than I do. I know there's an opportunity to learn there.
--
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


 
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/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

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

I do, by the way, seem to leave behind clients, some of whom do a very
good job of carrying on the practices I teach them. I don't know what in
particular makes our experiences differ so much.

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

Certainly entity classes typically need only one implementation, and
value objects are the same. Infrastructure-related service classes
(persistence, authorization), though, are typically good candidates for
interfaces, even if business-related service class are less so.

So it's true that most classes simply do not need more than one
implementation. I don't extract interfaces from most of the classes I write.

Take care.
--
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


 
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/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

>  > Unless you're testing.
>
> I disagree with that too. :-) I much prefer to test the actual classes
> rather than mock classes. Doing so I often discover bugs that aren't at
> all what I expected and that would have been missed by mock testing. The
> thorniest bugs are often at the intersections between classes rather
> than in the classes themselves.

I gather your test suites run quickly enough to get enough feedback to
keep you happy. Mine don't, so I want faster feedback, and more stuff
running in memory makes that happen.

A question: when you test business logic that touches a relational
database, do you just put up with how slow those tests are? If not, what
do you do? HSQLDB? Something else?

> Like interfaces, mocks have their place; but also like interfaces, that
> place is often seen to be broader than it really is.

This is certainly the case for those learning to use these techniques.
If you don't first underdo it, then overdo it, how do you do know how
much is enough?
--
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


 
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/
 

[J. B. Rainsberger]

Cédric Beust ♔ wrote:

> On 8/15/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>> wrote:
>  >
>  > Cédric Beust ♔ wrote:
>  >
>  > > Design driven by tests is not necessarily better than design driven by
>  > > careful thought from an experienced developer.
>  >
>  > Aha! Aha! Aha!
>  >
>  > Driving my designs by tests is /how I became/ an experienced programmer
>  > who thinks carefully!
>
> Good for you, but a lot of people were already experienced programmers way
> before TDD came about...

Were they experienced programmers /who think carefully/? Some were; some
weren't. For the ones that weren't/aren't, TDD provides a thinking
model. I don't see a problem with that.

For the rest, I don't care whether they do TDD or not, unless they're on
my team, because we need to agree on a set of practices and perform them.

> TDD is not better than a "design driven by careful thought", precisely
>  > because TDD is /a method for thinking carefully about a design/!
>
> TDD can also lead to subpar design, precisely because of the obsession over
> the tests at the exclusion of all other factors (such as, I don't know,
> customer satisfaction :-)).

Can we please stop saying trivial things like "Practice X doesn't
automatically make people smart programmers"? That bores me.

Take care.
--
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


 
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/
 

[J. B. Rainsberger]

Cédric Beust ♔ wrote:

> On 8/15/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>> wrote:
>  >
>  >
>  > > I'm not sure I follow the reasoning. Just because you don't do TDD
>  > doesn't
>  > > mean you produce code that is not easily testable...
>  >
>  > Strictly speaking, no, but the correlation between not writing the test
>  > first and writing difficult-to-test code is pretty high, don't you think?
>
> Yes, it's pretty obvious that code written with TDD is code that is easily
> testable, by definition.
>
> 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.

Agreed. I never claimed that (but you probably aren't implying I did).
Anyone who claims that is an idiot.

> If the developer is
> experienced, she will produce testable code, whether she uses TDD or not.

Trivially wrong, due to the absoluteness of the statement. See Shane's
comment that experienced != good.

> 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".

Obviously. Doing TDD 100% of the time is how to learn TDD, not how to
ship good software.

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

That feels like a challenge. I'd be interested to hear about them, even
though I don't have the energy to try them.

Take care.
--
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


 
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/
 

[J. B. Rainsberger]

Simon Chappell wrote:

>
>
> On 8/15/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>> 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.

Of course not! Please don't try to tell me that good software only comes
from TDD. I am not falling for that.
--
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


 
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/17/06, J. B. Rainsberger <jbrains@...> wrote:

>
> Elliotte Harold wrote:
>
> >  > Unless you're testing.
> >
> > I disagree with that too. :-) I much prefer to test the actual classes
> > rather than mock classes. Doing so I often discover bugs that aren't at
> > all what I expected and that would have been missed by mock testing. The
> > thorniest bugs are often at the intersections between classes rather
> > than in the classes themselves.
>
> A question: when you test business logic that touches a relational
> database, do you just put up with how slow those tests are? If not, what
> do you do? HSQLDB? Something else?

I know you're asking Elliotte but that won't stop me from sharing my
experience :-)

In my opinion, the slowness of database tests is vastly exaggerated.

Don't over-estimate the time taken to contact a localhost database until you
actually start watching the clock tick while your tests run.  And in my
experience, it takes a lot of databases, tables and complex queries to get
there.

Nowadays, databases and networks are extremely fast, so don't optimize
prematurely.  Test the "real code" and wait until the tests start taking a
long time before deciding on a course of action (and when such a thing
happens, I will usually choose not to use mock objects and split my tests
further into "slow" and "fast" groups).

Like Elliotte, I like testing real objects, but I don't hesitate to use
interfaces whenever it makes sense.

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

[J. B. Rainsberger]

Robert Martin wrote:

>  > > 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.
>
> I'm quite happy to stand by that claim. Over the last 7 years I have
> come to the following conclusions:
>
> 1. There are no instances in which TDD is impossible.
> 2. There are no instances in which TDD is not advantageous.
> 3. The impediments to TDD are human, not technical.
> 4. The alternative to TDD is code that is not repeatably testable.
>
> Therefore I consider TDD to be a minimum professional standard.
> Developers who do not use TDD fall below that standard.

I can't quite agree with that, but I would be thrilled to wake up one
morning to find out that it's true. If that became /the/ minimum
professional standard (whatever that would mean), I wouldn't complain.
--
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


 
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/
 

[Shane Mingins-2]

On 8/18/06, Robert Martin <UncleBob@...> wrote:
>
>   Take a look at the Rails framework. This is a web-development
> framework that has testing built in from the very start. Virtually
> every facet of a rails application is intended to be written using
> TDD. The point is that the new hyper-productive frameworks are
> adopting TDD from the get-go.
>
>







Not disputing this point (as I have only been using Rails now for a week or
total and so far I love the testing capabilities that I have seenl) but I
was disappointed that the Pragmatic Series book Agile Web Development with
Rails has no coverage of applying TDD with Rails.

One could argue that this was not the point of the book, that it is about
learning the Rails framework but I just expected to see some mention and
demonstration of it by either Dave Thomas of Mike Clark.

Perhaps when I have moved further along I may change my opinion on this :-)

Cheers
Shane


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

[Ilja Preuss-2]

EmpereurYollson schrieb:
> Hi may i move my adress from the list please

Sure. Did you read the footer?





 
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]

J. B. Rainsberger wrote:

> I gather your test suites run quickly enough to get enough feedback to
> keep you happy. Mine don't, so I want faster feedback, and more stuff
> running in memory makes that happen.

Sometimes you need to do that, but when that happens I tend to split the
test suite into a full version and a compact version. The full version
can be run automatically and repeatedly on a build server. If it takes
an hour or even 24 hours to run, it's no big deal, as long as the
compact version runs quickly.

I also sometimes reorganize test suites so I run just the subset that
seems most likely to touch the code I'm working on. That can also reduce
build times to manageable levels.

> A question: when you test business logic that touches a relational
> database, do you just put up with how slow those tests are? If not, what
> do you do? HSQLDB? Something else?
>

I haven't done a lot of RDB testing. My slowest tests mostly involve
network connections and web servers. For that, I either put up with the
slowness or subset the tests as described above. I suppose I could build
  a web server into my test suite, but honestly that's never been the
simplest thing that could possibly work for me. :-) If it ever becomes a
major problem, I might consider it.

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

[unclebob]

> Not disputing this point (as I have only been using Rails now for a  
> week or
> total and so far I love the testing capabilities that I have seenl)  
> but I
> was disappointed that the Pragmatic Series book Agile Web  
> Development with
> Rails has no coverage of applying TDD with Rails.
>
> One could argue that this was not the point of the book, that it is  
> about
> learning the Rails framework but I just expected to see some  
> mention and
> demonstration of it by either Dave Thomas of Mike Clark.

I was disappointed too.  Mike's chapter was very good, but it was  
almost pointedly devoid of TDD.  The test-later approach that the  
chapter took left the example relatively untested.

Nevertheless I am very pleased with the testing orientation of Rails,  
and am looking forward to seeing that very active and energetic  
community continue to embrace the disciplines of TDD.


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

> > 1. There are no instances in which TDD is impossible.
> > 2. There are no instances in which TDD is not advantageous.
> > 3. The impediments to TDD are human, not technical.
> > 4. The alternative to TDD is code that is not repeatably testable.
> >
> > Therefore I consider TDD to be a minimum professional standard.
> > Developers who do not use TDD fall below that standard.
>
> I can't quite agree with that, but I would be thrilled to wake up one
> morning to find out that it's true. If that became /the/ minimum
> professional standard (whatever that would mean), I wouldn't complain.

I'm not quite sure I know what you are disagreeing and agreeing with.

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