Are you really using JUnit during your development?

[Ilja Preuss-2]

Cédric Beust:

> It can be argued that writing test firsts can be detrimental to your
> velocity because it introduces churn: you don't know yet what your final
> code will look like, and before you reach something you're comfortable with,
> you might have to rewrite it two or three times. And every time, you will
> have to modify these tests as well. TDD can be a big waste of time.
>
> Here is why.
>
> With test first, you have something like: Test v1, Code v1, Test v2, Code
> v2, Test v3, Code v3. Check in.
>
> If you postpone your testing a bit, you have: Code v1, Code v2, Code v3,
> Test v3, Commit.
>
> The latter approach will get you to your goal much faster.

That an interesting hypothesis. In fact it sounds quite logical. It just
doesn't survive the check against reality, in my experience.

Take care, Ilja


 
Yahoo! Groups Links

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

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

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

[Jeff Nielsen]

Cédric Beust wrote:

> It can be argued that writing test firsts can be detrimental to your
> velocity because it introduces churn: you don't know yet what your
> final code will look like, and before you reach something you're
> comfortable with, you might have to rewrite it two or three times.
> And every time, you will have to modify these tests as well.  TDD
> can be a big waste of time.
>
> Here is why.
>
> With test first, you have something like: Test v1, Code v1, Test v2,
> Code v2, Test v3, Code v3.  Check in.
>
> If you postpone your testing a bit, you have: Code v1, Code v2, Code
> v3, Test v3, Commit.
>
> The latter approach will get you to your goal much faster.

Taken to the next level, this is the kind of reasoning that leads to
phase-based SW dev. schedules rather than iterative ones.  On paper,
it looks like it will be more efficient to write a bunch of code and
then test/integrate it at once, rather than do acceptance testing and
integration iteration-by-iteration or story-by-story.  On paper, it
looks like lots of re-work to test & integrate the code every day
rather than once every couple of weeks/months after features are
"stable."  (It also looks more efficient to do the requirements work
all at once, to save the requirements people time.)

A phase-based, batch approach only turns out to be more efficient if

  * The tasks to be done are fairly well understood & somewhat
    repetitive

  * The dominant cost of the work /is/ in the repetitive labor

This doesn't seem to hold true with programming, for me at least.  I
usually find that the dominant cost is in the thinking, learning, and
communication, rather than in the typing.  All that stuff that looks
like re-work on paper is actually speeding up my ability to think,
learn, and communicate.


--
Jeff Nielsen
Digital Focus
www.digitalfocus.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]

David Saff wrote:

> Cedric,
>
> I think we disagree here, but before I say more, I'd like to know how
> much. I hear that "It _can be argued_ that writing test firsts can be
> detrimental to your velocity", and then "TDD _can be_ a big waste of
> time", and then "The latter approach _will_ get you to your goal much
> faster". Which of these is your personal experience?

I have a different question to ask. In my experience, TDD makes me go
faster on average. If Cedric allows this to be true, then how does he
propose I identify those cases where TDD would not make me go faster?

Not to be glib, but if I knew when that would happen, I would have a
mansion on Grand Cayman already.

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

>  > > Here is why.
>  > >
>  > > With test first, you have something like: Test v1, Code v1, Test v2,
>  > Code
>  > > v2, Test v3, Code v3. Check in.
>  > >
>  > > If you postpone your testing a bit, you have: Code v1, Code v2, Code
>  > v3,
>  > > Test v3, Commit.

In 2004 I hosted an Open Space session about _JUnit Recipes_. I asked
readers and would-be readers of the book to join me and ask me questions
about testing, TDD and JUnit.

One person ventured that there "wasn't much difference" between writing
the test first and the code first, so he wondered why I stressed writing
the test first. Here is a rough approximation of my answer.

"Well, first, let me ask you what happens when you write the code first,
then test it. There are a few possibilities:

  * write the code, write the tests, they pass, all is well
  * write the code, write the tests, one fails, debug
  * write the code, find it difficult to write the tests, rewrite the
code to be easier to test

"I'm sure there are more, but that's good enough for now. I imagine
you've experienced all three of these. [He had.] Now take a guess how
often #2 and #3 happen. [He guessed around half the time for each.] Take
a guess how often #1 happens. [He guessed less than half the time.] Now
let's do a little computation.

"Suppose that 1/2 the time, you get happy path #1. That means that 1/2
of 1/2 the time, or 1/4 of the time, you write the code, then either
have to rewrite it to write the tests, or write a test that causes the
code to fail. If you had written the tests first, that 1/4 of the time
would disappear, and the 1/2 of the time you get happy path #1 wouldn't
be any different.

"Now that I think of it, that's wrong. Path #3 is like refactoring to be
able to add the next feature. Suppose that that cost is the same. Now,
somewhere between a negligible amount of time and 1/4 of the time, TDD
helps you by reducing the likelihood you'll write code that fails a test
you know you need to write, because by writing the test first, you won't
stop after writing code that fails the test.

"Now notice that this is a /best/ case scenario, based on your
experience. It's likely that you get happy path #1 less than 1/2 the
time, so the number of times you hit paths #2 and #3 is greater. This
increases the cost of test-second compared to test-first."

Let's bring this back to your example.

 >  > > With test first, you have something like: Test v1, Code v1, Test v2,
 >  > Code
 >  > > v2, Test v3, Code v3. Check in.
 >  > >
 >  > > If you postpone your testing a bit, you have: Code v1, Code v2, Code
 >  > v3,
 >  > > Test v3, Commit.

If you postpone your testing a bit, you have: Code v1, Code v2, Code v3,
Test v0.1, Code v3.1, Test v0.2, Code v3.2, Test v1, Code v3.3, Commit.
This is because the act of writing the tests exposes flaws in the design
that make the test difficult to 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]

Ravi k wrote:

> hi
>
> plz send if u have PDF for mock objects as Testing.

hi

plz start a new thread instead of replying when you start a new topic.

Also, please try Google's advanced search to find PDFs related to "mock
objects".

http://www.google.com/advanced_search?hl=en
--
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/
 

[kentb]

One factor that complicates this discussion (besides the overall lack of
civility) is that tools, techniques, and culture are changing quickly. When
person A says, "You can't test everything," and person B says, "Yes, you
can," they can both be right from their perspective if person B has access
to tools or techniques that person A does not. The cultural aspect of
developer testing that further muddies the waters is that the global
develoment community is changing quickly but unevenly. Once again, person A
can say, "You ought to write tests," and person B can say, "You don't need
to write tests," and they can both be correct from their perspective.  More
precisely, one person could say, "I think it is my duty as a programmer to
write thorough, automated tests," and the other say, "I think testing is one
of many priorities that need to be balanced so it is my duty as a programmer
to sometimes skip writing automated tests," and they could both be
expressing valid opinions.
 
Yours,
 
Kent Beck
Three Rivers Institute


  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Joakim Ohlrogge
Sent: Friday, August 04, 2006 3:25 AM
To: junit@...
Subject: Re: [junit] Re: Are you really using JUnit during your development?



Slightly out of order, I moved the "above" to "below".

> Just reread what I wrote above and you'll see six tasks in the first case
> and four tasks in the second one. Isn't it obvious that quite often, the
> former approach will take longer than the latter?

I think it _can_ be like that but it is often hard to know up front
when it _will_ be like that. What you're after, I think, is to compare
"TDD religiously" to "TDD pragmatically". The second sure has a nice
ring to it compared to the first. The advantage of the first IMO is
that you never have to think wether to go one way or the other, you
just "do" which also saves time given that it is the right descision
most of the time.

Now to your "above" examples that I moved to be "below":

> > > With test first, you have something like: Test v1, Code v1, Test v2,
> > Code
> > > v2, Test v3, Code v3. Check in.

To me Test v1, Code v1, Test v2, code v2, Test v3, Code v3. Check in.
sounds bigger than:
Test a little, code a little, test a little, code a little, test a
little code a little. Check in

> > > If you postpone your testing a bit, you have: Code v1, Code v2, Code
> > v3,
> > > Test v3, Commit.

While this sure /looks/ attractive I think the comparison seems overly
simplified. I have a few questions:

- I'm not convinced that the tasks are of the same size in your two
examples. Can you really just count them to make a conclusion which is
faster?

- A big part of writing a test is thinking about how something should
work so that you can code it. I don't see that part disapearing when
you remove the test. Question is, will thinking be easier, harder or
the same when you defer the test-part?

- If you can code it, you know how it works... then shouldn't writing
a test be fast?

- If you don't know how to code it so that you have to redo things a
couple of times. Aren't tests good for exploring those situations?
Couldn't it even be faster or to you do things in more steps?

- Will the above be faster/better for beginners or experienced coders?
In your opinion does it matter?

- What about the design? Do you think you will have the same
advantages when "retrofitting" tests or does that depend on who wrote
the code initially?

You can always make the choice to write the tests after but wouldn't
you be missing out on a lot of the really good stuff?

> > >
> > > The latter approach will get you to your goal much faster.

I think in /most/ situations, from /my/ experience /I/ disagree.

/Joakim Ohlrogge


 



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



 
Yahoo! Groups Links

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

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

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

[Simon Chappell]

"Go not to the elves for council for they will answer both yes and no!"

Errr, Kent, do you have pointy ears? :-)

Simon

On 8/8/06, Kent Beck <kentb@...> wrote:

> One factor that complicates this discussion (besides the overall lack of
> civility) is that tools, techniques, and culture are changing quickly. When
> person A says, "You can't test everything," and person B says, "Yes, you
> can," they can both be right from their perspective if person B has access
> to tools or techniques that person A does not. The cultural aspect of
> developer testing that further muddies the waters is that the global
> develoment community is changing quickly but unevenly. Once again, person A
> can say, "You ought to write tests," and person B can say, "You don't need
> to write tests," and they can both be correct from their perspective.  More
> precisely, one person could say, "I think it is my duty as a programmer to
> write thorough, automated tests," and the other say, "I think testing is one
> of many priorities that need to be balanced so it is my duty as a programmer
> to sometimes skip writing automated tests," and they could both be
> expressing valid opinions.
>
> Yours,
>
> Kent Beck
> Three Rivers Institute

--
www.simonpeter.org


 
Yahoo! Groups Links

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

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

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

[J. B. Rainsberger]

Simon Chappell wrote:

> "Go not to the elves for council for they will answer both yes and no!"
>
> Errr, Kent, do you have pointy ears? :-)

He doesn't, but he has what I might call an elfish sense of humor.
--
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/
 

[Simon Chappell]

On 8/8/06, J. B. Rainsberger <jbrains@...> wrote:
> Simon Chappell wrote:
>
> > "Go not to the elves for council for they will answer both yes and no!"
> >
> > Errr, Kent, do you have pointy ears? :-)
>
> He doesn't, but he has what I might call an elfish sense of humor.

Then, I'd better apologise for goblin up the list's bandwidth. :-)

--
www.simonpeter.org


 
Yahoo! Groups Links

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

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

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

[Cédric Beust ♔]

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

>
> Cédric Beust ♔ wrote:
>
> > You seem to imply that there are only two kinds of code:
> >
> > - Code that is tested and works
> > - Code that is not tested and doesn't work
> >
> > There is actually something in the middle: it's called "Code that is not
> > tested but that works".
>
> There is no such thing as code that is not tested, but works. Or, that
> is only a theoretical existence, since you can't know such code exists,
> until you test it, even if only by using it.

You can, because if it doesn't work, your users will let you know.

> It's a fairly common occurrence, in my experience, and the reason behind
> my
> > comments earlier: if other circumstances warrant it, it's okay to write
> the
> > code, ship it and write the tests later.
>
> If it doesn't have to work, that's fine.


It does, otherwise the company will shut down.

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

On 8/7/06, J. B. Rainsberger <jbrains@...> wrote:
>
>
>
>   * write the code, write the tests, they pass, all is well
>   * write the code, write the tests, one fails, debug
>   * write the code, find it difficult to write the tests, rewrite the


Interestingly, you leave out the case that I was precisely making my
argument on:

* write the code, rewrite the code, rewrite the code, and finally you're
happy with this v1 and you check it in.

This is fairly common in my experience, and I was simply arguing that in
such cases, TDD might end up introducing extra work.


> If you postpone your testing a bit, you have: Code v1, Code v2, Code v3,
> Test v0.1, Code v3.1, Test v0.2, Code v3.2, Test v1, Code v3.3, Commit.
> This is because the act of writing the tests exposes flaws in the design
> that make the test difficult to write.


Sometimes, sure.  Other times, you're just wasting time writing tests for
code that you will throw away.

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

On 8/7/06, J. B. Rainsberger <jbrains@...> wrote:
>
>
> I have a different question to ask. In my experience, TDD makes me go
> faster on average. If Cedric allows this to be true, then how does he
> propose I identify those cases where TDD would not make me go faster?


It's never really.  In my experience, any task that's a bit more complex
than, say, a Money or a Bowling example, is probably something you should
think twice before you TDD.

Also, knowing the final goal is different from knowing the API you will need
to reach that goal, so then again, I would probably think hard and make sure
that going TDD is not going to make me lose.

Not to be glib, but if I knew when that would happen, I would have a
> mansion on Grand Cayman already.


Avoid the East Side of the island, it's still recovering from Ivan.
Georgetown is pretty, though.

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

[J. B. Rainsberger]

Cédric Beust ♔ wrote:

> On 8/3/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>> wrote:
>  >
>  > Cédric Beust ♔ wrote:
>  >
>  > > You seem to imply that there are only two kinds of code:
>  > >
>  > > - Code that is tested and works
>  > > - Code that is not tested and doesn't work
>  > >
>  > > There is actually something in the middle: it's called "Code that
> is not
>  > > tested but that works".
>  >
>  > There is no such thing as code that is not tested, but works. Or, that
>  > is only a theoretical existence, since you can't know such code exists,
>  > until you test it, even if only by using it.
>
> You can, because if it doesn't work, your users will let you know.

My point: that means you're forcing your users to test it, rather than
testing it yourself.

>  > It's a fairly common occurrence, in my experience, and the reason behind
>  > my
>  > > comments earlier: if other circumstances warrant it, it's okay to write
>  > the
>  > > code, ship it and write the tests later.
>  >
>  > If it doesn't have to work, that's fine.
>
> It does, otherwise the company will shut down.

I can swing a dead cat and hit 10 companies that make money on software
that doesn't work.

To avoid this conversation looping endlessly, let me summarize my view:

  * Not all software in use works
  * There are many users that somewhat successfully use software that
doesn't work
  * There are many companies that stay in business in spite of the fact
that the software they produce doesn't work
  * Over several decades, we as an industry have trained users to be
satisfied with shit software, so when they get decent software (that is,
not tested, but works fairly well), they are delighted
  * I think this state of affairs is holding us back from really doing
Good Work with software
  * A well-run business that produced great software could kill,
especially after Mr Gates exits from Microsoft (I couldn't resist that
last bit)
  * Therefore, I do my part by trying to produce great software, instead
of software that isn't quite shit; I try to surround myself with people
who can build a well-run business

I hope that does it.
--
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/7/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>> wrote:
>  >
>  >
>  >
>  > * write the code, write the tests, they pass, all is well
>  > * write the code, write the tests, one fails, debug
>  > * write the code, find it difficult to write the tests, rewrite the
>
> Interestingly, you leave out the case that I was precisely making my
> argument on:
>
> * write the code, rewrite the code, rewrite the code, and finally you're
> happy with this v1 and you check it in.

Why are you "happy with this v1"? To me, that's the problem: why would
one be happy with code that only sorta kinda works?

> This is fairly common in my experience, and I was simply arguing that in
> such cases, TDD might end up introducing extra work.

Of course, if the code doesn't have to work, then TDD is more effort
than you need.

>  > If you postpone your testing a bit, you have: Code v1, Code v2, Code v3,
>  > Test v0.1, Code v3.1, Test v0.2, Code v3.2, Test v1, Code v3.3, Commit.
>  > This is because the act of writing the tests exposes flaws in the design
>  > that make the test difficult to write.
>
> Sometimes, sure. Other times, you're just wasting time writing tests for
> code that you will throw away.

I think you might be describing some kind of exploratory design by
writing code. It looks like you mean you write code, rewrite it to
improve the design, rewrite it to improve the design, then check it in.
If that's the case, the TDD is not extra work, it's less. Here's why:

If you don't to TDD, then you end up reworking code until you like the
design, but then afterwards you need to test it to see whether it works.
Either you test it manually, say in a debugger, which is slow; or you
test it with printf()s, which generally requires you to add them at the
right place, check the results, then remove them, which is slow; or you
add automated tests, which is often slow because you probably (1) wrote
too much code at once and (2) wrote code that isn't easily tested. As a
result, you usually (p > 0.5) rewrite the code to make it testable, then
add tests.

If you do TDD, then when you write the tests, you are designing before
you cast the algorithm into code. You get the opportunity to evaluate
the external design before you fill in the details. By refactoring in
small steps, you get the opportunity to improve the internal design as
you fill in the details, with the freedom to change the internal design
with confidence, rather than dipping into the debugger every few
minutes. You finally end up with code that is both well-tested and
well-designed, and almost certainly in less time than it takes to write
the code first, be happy with the design, then test is afterwards.

But, of course, if you don't need to test your code, then TDD is more
effort than not doing TDD. But then, there are two cases:

1. You're shipping shit, or
2. You're not shipping shit, which means you're a genius, which means
you go faster than everyone else, anyway, whether you practise TDD or not.

I just can't buy the notion that it's possible to write good, untested
code. Show it to me. Where is this good, untested code?
--
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/7/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>> wrote:
>  >
>  >
>  > I have a different question to ask. In my experience, TDD makes me go
>  > faster on average. If Cedric allows this to be true, then how does he
>  > propose I identify those cases where TDD would not make me go faster?
>
> It's never really. In my experience, any task that's a bit more complex
> than, say, a Money or a Bowling example, is probably something you should
> think twice before you TDD.

So I think you mean that TDD never makes me go faster? But my
observation is that TDD almost always makes me go faster. I have
rewritten months of code in weeks with TDD.

> Also, knowing the final goal is different from knowing the API you will need
> to reach that goal, so then again, I would probably think hard and make sure
> that going TDD is not going to make me lose.

I find that interesting. Do you believe that when I practise TDD that I
do not think? Do you believe that when I practise TDD that I think less
than when I didn't? In some ways, TDD is like doodling: it helps me work
through what I'm thinking about.

> > Not to be glib, but if I knew when that would happen, I would have a
> > mansion on Grand Cayman already.
>
> Avoid the East Side of the island, it's still recovering from Ivan.
> Georgetown is pretty, though.

Someday... someday...
--
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/
 

[Simon Chappell]

On 8/11/06, J. B. Rainsberger <jbrains@...> wrote:
!snip!
> 1. You're shipping shit, or
> 2. You're not shipping shit, which means you're a genius, which means
> you go faster than everyone else, anyway, whether you practise TDD or not.

I think it's safe to say that most versions of Microsoft Windows have
been Sierra Hotel 1 Tango, but apparently, that hasn't stopped it
selling. This says nothing good about our industry or our users, I
fear.

> I just can't buy the notion that it's possible to write good, untested
> code. Show it to me. Where is this good, untested code?

I still maintain that it's all about quality. TDD is a tool to help
you build quality in to your software. It isn't, nor should it be a
religion. I'm sure it's possible to write code that is "good enough"
without TDD, but it'll never be high quality.

And you'll never get code that's "good enough" accepted into flight
systems. They not only test the code, but they have independent
testers test the tests and certify the results. When Windows crashes
it's annoying, when airplanes crash, it's at the far end of bad.

It's all about how much quality you want in your code. Quality has to
be built in, you can't go back an bolt it on. I use TDD whenever
possible to build quality into my code. No one make me do it, but I
find that the more tests I write, the quicker I write them and the
quicker I get to working code.

Simon

--
www.simonpeter.org


 
Yahoo! Groups Links

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

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

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

[Carl Hume]

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

>
>
> "Well, first, let me ask you what happens when you write the code first,
> then test it. There are a few possibilities:
>
> * write the code, write the tests, they pass, all is well
> * write the code, write the tests, one fails, debug
> * write the code, find it difficult to write the tests, rewrite the
> code to be easier to test
>

You forgot one very important point:

* write the code, find it difficult to write the tests, test manually, move
along

In my experience, this happens far too often (guilty, your honour) and is
probably the biggest risk factor of writing the tests afterward.

Cheers!
Carl

--
http://genomescampaigns.blogspot.com


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



 
Yahoo! Groups Links

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

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

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

[Brett L. Schuchert]

>> From: Simon Chappell <simonpeterchappell@...>
>> religion. I'm sure it's possible to write code that is "good enough"
>> without TDD, but it'll never be high quality.
 
You just made a strong claim:
     Without TDD you'll never be high quality
 
TDD: Test Driven Design
     Write a test, get it to compile, get it to work
     Repeat
 
Space Shuttle control software does not use TDD, but apparently it is not high quality?
 
Apollo mission software did not use TDD, but apparently it is not high quality?
 
I wonder, when you write TDD, do you really mean using effective unit testing? Because it is not the same thing.
 
Did you really mean to write that?
 
Brett
 
Tutorials and Articles
     http://schuchert.wikispaces.com/



----- Original Message ----
From: Simon Chappell <simonpeterchappell@...>
To: junit@...
Sent: Friday, August 11, 2006 7:58:08 AM
Subject: Re: [junit] Re: Are you really using JUnit during your development?

On 8/11/06, J. B. Rainsberger <jbrains@rogers. com> wrote:
!snip!
> 1. You're shipping shit, or
> 2. You're not shipping shit, which means you're a genius, which means
> you go faster than everyone else, anyway, whether you practise TDD or not.

I think it's safe to say that most versions of Microsoft Windows have
been Sierra Hotel 1 Tango, but apparently, that hasn't stopped it
selling. This says nothing good about our industry or our users, I
fear.

> I just can't buy the notion that it's possible to write good, untested
> code. Show it to me. Where is this good, untested code?

I still maintain that it's all about quality. TDD is a tool to help
you build quality in to your software. It isn't, nor should it be a
religion. I'm sure it's possible to write code that is "good enough"
without TDD, but it'll never be high quality.

And you'll never get code that's "good enough" accepted into flight
systems. They not only test the code, but they have independent
testers test the tests and certify the results. When Windows crashes
it's annoying, when airplanes crash, it's at the far end of bad.

It's all about how much quality you want in your code. Quality has to
be built in, you can't go back an bolt it on. I use TDD whenever
possible to build quality into my code. No one make me do it, but I
find that the more tests I write, the quicker I write them and the
quicker I get to working code.

Simon

--
www.simonpeter. 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/
 

[Vishal Vishnoi]

About

+++++++++
 >>My point: that means you're forcing your users to test it, rather than
 >>testing it yourself.
++++++++++

The reality is that as your features increase the number of tests you
have to write to cover all permutation and combination skyrockets. Not
to mention all the interop, system , RAS and performance test that needs
to be done in addition to the basic feature test.

You can never possibly test all of them. Otherwise, you will never
deliver any product. If you able to do it, then I've to assume that the
product consists of only 1 to 10 classes and not more than 5-10 public
methods, and even for that the # of tests to cover all combination is huge.

So, the reality is that there will always be some code, which is run in
some combination, which has not been tested. It is the job of the
product Dev and QA architect, and leads to judiciously choose the right
set of tests which provide maximum coverage (note, I don't mean code
coverage, as high code coverage can give a false sense of security).

I don't believe in extremes like "No tests" or "tests every possible
combination". There is a middle ground which practical people realize
and strive to achieve.

peace,

--Vishal

J. B. Rainsberger wrote:

> Cédric Beust ♔ wrote:
>
> > On 8/3/06, J. B. Rainsberger <jbrains@...
> <mailto:jbrains%40rogers.com>
> > <mailto:jbrains%40rogers.com>> wrote:
> > >
> > > Cédric Beust ♔ wrote:
> > >
> > > > You seem to imply that there are only two kinds of code:
> > > >
> > > > - Code that is tested and works
> > > > - Code that is not tested and doesn't work
> > > >
> > > > There is actually something in the middle: it's called "Code that
> > is not
> > > > tested but that works".
> > >
> > > There is no such thing as code that is not tested, but works. Or, that
> > > is only a theoretical existence, since you can't know such code
> exists,
> > > until you test it, even if only by using it.
> >
> > You can, because if it doesn't work, your users will let you know.
>
> My point: that means you're forcing your users to test it, rather than
> testing it yourself.
>
> > > It's a fairly common occurrence, in my experience, and the reason
> behind
> > > my
> > > > comments earlier: if other circumstances warrant it, it's okay
> to write
> > > the
> > > > code, ship it and write the tests later.
> > >
> > > If it doesn't have to work, that's fine.
> >
> > It does, otherwise the company will shut down.
>
> I can swing a dead cat and hit 10 companies that make money on software
> that doesn't work.
>
> To avoid this conversation looping endlessly, let me summarize my view:
>
> * Not all software in use works
> * There are many users that somewhat successfully use software that
> doesn't work
> * There are many companies that stay in business in spite of the fact
> that the software they produce doesn't work
> * Over several decades, we as an industry have trained users to be
> satisfied with shit software, so when they get decent software (that is,
> not tested, but works fairly well), they are delighted
> * I think this state of affairs is holding us back from really doing
> Good Work with software
> * A well-run business that produced great software could kill,
> especially after Mr Gates exits from Microsoft (I couldn't resist that
> last bit)
> * Therefore, I do my part by trying to produce great software, instead
> of software that isn't quite shit; I try to surround myself with people
> who can build a well-run business
>
> I hope that does it.
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.info 
> <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
>
>  

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.


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

[kentb]

Cédric,
 
I take an optimistic view of TDD. When I can figure out the mechanics of it,
it has always helped me develop with more confidence, fewer defects, and a
cleaner design. Sometimes I can't (yet) figure out how to do it, and then I
find other ways to get feedback. When I defer TDD, I work on it
subconsciously and sometimes come with a way to accomplish it a few weeks or
months later.
 
Regards,
 
Kent Beck
Three Rivers Institute



  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Cédric Beust ?
Sent: Thursday, August 10, 2006 9:36 PM
To: junit@...
Subject: Re: [junit] Re: Are you really using JUnit during your development?



On 8/7/06, J. B. Rainsberger <jbrains@rogers. <mailto:jbrains%40rogers.com>
com> wrote:
>
>
> I have a different question to ask. In my experience, TDD makes me go
> faster on average. If Cedric allows this to be true, then how does he
> propose I identify those cases where TDD would not make me go faster?

It's never really. In my experience, any task that's a bit more complex
than, say, a Money or a Bowling example, is probably something you should
think twice before you TDD.

Also, knowing the final goal is different from knowing the API you will need
to reach that goal, so then again, I would probably think hard and make sure
that going TDD is not going to make me lose.

Not to be glib, but if I knew when that would happen, I would have a
> mansion on Grand Cayman already.

Avoid the East Side of the island, it's still recovering from Ivan.
Georgetown is pretty, though.

--
Cédric

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



 



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



 
Yahoo! Groups Links

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

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

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