Are you really using JUnit during your development?

[Simon Chappell]

Brett,

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.

Now, TDD is not JUnit, after all, JUnit is just a library. TDD is at
it's most basic, a philosophy. This means that anytime you are
developing with a positive feedback loop from your tests, you are
doing TDD.

Now, as I have already mentioned a few times in this thread, I have a
friend who works for a aeronautical testing company. They are called
in to perform third-party independent verification of tests and test
results for flight systems. When flight systems are designed, their
complete behaviour is specified up front. The code and the tests are
written and then when all of the tests pass, the code is handed over
to the third-party folks for verification.

You can argue that this isn't TDD, and I wouldn't argue the point too
hard, but the basic philosophy is compatible. They think carefully
about what they want, they define the desired behaviour including what
the tests should test and then the developers get to work and then
there is another round where the third-party verification provides
feedback on the tests and how well they satisfy the original
requirements. Hmmmm, that sounds like something I've seen around here.
:-)

Quality is caring. http://simonpeter.org/technology/writings/thirdlaw.html

Without caring, even someone who is mandated to use TDD is going to
churn out Sierra Hotel 1 Tango. I've seen it done. At my previous
employer, unit tests were mandated, so some developers created unit
tests but never made any assertions about expected results. Naturally
the tests passed, because they never actually tested anything and
therefore could never fail.

While I'm fully in favour of TDD, without caring, TDD cannot work.
Without caring, non-TDD development techniques can't work either.
Without caring, even the aeronautical testing won't work.

If you do care about quality, I assert (pun intended) that TDD is the
most effective converter of caring into software quality.

Simon

--
www.simonpeter.org


On 8/11/06, Brett L. Schuchert <schuchert@...> wrote:

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

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

On 8/12/06, Simon Chappell <simonpeterchappell@...> wrote:
>
> Brett,
>
> 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.


Again, this is a very bold claim, and one that is easy to challenge.

Assume that you write a high-quality product using TDD, I can write this
exact same high-quality product using all your same tests, except I won't
have written them first.  And voila, high-quality software without ever
using TDD.

The truth is:  the main impact that TDD has when you develop software is on
its design, not its quality.  Hence the last "D" in "TDD".  I definitely
believe that software written using TDD will have a very different
architecture from another software delivered with standard testing
techniques ("write the code, write the test, repeat").  But until you take a
look at the tests themselves, you can't compare their quality just based on
the testing methodology that was used.  After all, someone could be claiming
to do TDD and only write one test (or tests that do no asserts) while the
other non-TDD person will have written 1000 tests, and will therefore come
up with higher quality code.

I also believe that "the simplest thing that can possibly work" can lead to
very bad design, but I'll save this for a different thread.

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

[Simon Chappell]

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

> Hi Simon,
>
> On 8/12/06, Simon Chappell <simonpeterchappell@...> wrote:
> >
> > Brett,
> >
> > 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.
>
>
> Again, this is a very bold claim, and one that is easy to challenge.

So challenge it already.

> Assume that you write a high-quality product using TDD, I can write this
> exact same high-quality product using all your same tests, except I won't
> have written them first.  And voila, high-quality software without ever
> using TDD.

If you use my existing tests, then the design will still have been
created by working on the tests first. Therefore your point is in
error.

> The truth is:  the main impact that TDD has when you develop software is on
> its design, not its quality.  Hence the last "D" in "TDD".  I definitely

Good quality comes from good design. (and caring and testing). So
again, you actually enforce my point.

> believe that software written using TDD will have a very different
> architecture from another software delivered with standard testing
> techniques ("write the code, write the test, repeat").  But until you take a
> look at the tests themselves, you can't compare their quality just based on
> the testing methodology that was used.  After all, someone could be claiming
> to do TDD and only write one test (or tests that do no asserts) while the
> other non-TDD person will have written 1000 tests, and will therefore come
> up with higher quality code.

Claiming to do TDD is not doing TDD. I'm talking here only about those
that care and are seeking to create quality software products.

> I also believe that "the simplest thing that can possibly work" can lead to
> very bad design, but I'll save this for a different thread.

My observation in 27 years of tinkering with computers and 17 years of
earning my living with them, is that the simplest thing possible is
usually the best thing to do. I'd be glad to discuss that in a
different thread as well. :-)

http://simonpeter.org/technology/writings/fifthlaw.html

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/
 

[Cédric Beust ♔]

On 8/12/06, Simon Chappell <simonpeterchappell@...> wrote:
>
>
> Good quality comes from good design. (and caring and testing). So
> again, you actually enforce my point.


No, because TDD doesn't necessarily equate good design.  You don't magically
come up with a good design when you do TDD.

It's really about the developer.  If she's good, she'll produce good tests
and high quality software regardless of whether she uses TDD or not.

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

[Stephen Smith-2]

Cedric,

Isn't a dangerous assumption that your users will be sufficiently
competent/knowledgeable about your software to identify bugs?

Test cases are the only reliable indicator of code quality _and_ code
reliability, and because they are automated gives me far greater
confidence in the integrity of the code I write.

Kent's argument has always worked for me - TDD when you can, think about
it when you can't.

Regards,

Steve.
--
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/

Cédric Beust ♔ wrote:

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

 
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/12/06, Cédric Beust ♔ <cbeust@...> wrote:
> On 8/12/06, Simon Chappell <simonpeterchappell@...> wrote:
> >
> >
> > Good quality comes from good design. (and caring and testing). So
> > again, you actually enforce my point.
>
>
> No, because TDD doesn't necessarily equate good design.  You don't magically
> come up with a good design when you do TDD.

You get quality from a having a good design. TDD is an important tool
in the toolchest of good programmers to help arrive at good designs.
It's not the be all and end all of good design, but it sure helps.

> It's really about the developer.  If she's good, she'll produce good tests
> and high quality software regardless of whether she uses TDD or not.

Any developer who cares will do better work than one who doesn't. But
I also suggest that a developer that cares and uses TDD will do better
than one who cares and doesn't use TDD. I get suspicious when a
programmer says that they care and yet they don't want to use TDD.
Tell me again how not creating easily testable code increases quality?

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/
 

[Brett L. Schuchert]

Simon,
 
OK, based on your working definition of TDD, I agree that without it, you won't produce the same level of quality code. But then all you're really saying is we need a feedback look and we need to care about what we are doing.
 
However, that brings to light the fact that TDD means different things to different people. I *think*, for example, that TDD for Bob Martin means Test first, write one test, get it to work, etc, as he describes with the bowling example in his last book.
 
As for your definition of quality, I don't agree with it. I use Jerry Weinberg's definition:
   Quality = value to someone
 
So I cannot, for example, with all the caring in the world make something of quality for someone else. Caring is probably necessary but not sufficient. They have to decide that what they got is useful to them and therefore is of quality.
 
I will agree that without caring you're not likely to develop something that has quality for someone else. By caring, you'll talk to the person who wants the thing.
 
Tutorials and Articles
     http://schuchert.wikispaces.com/



----- Original Message ----
From: Simon Chappell <simonpeterchappell@...>
To: junit@...
Sent: Saturday, August 12, 2006 9:40:02 AM
Subject: Re: [junit] Re: Are you really using JUnit during your development?

Brett,

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.

Now, TDD is not JUnit, after all, JUnit is just a library. TDD is at
it's most basic, a philosophy. This means that anytime you are
developing with a positive feedback loop from your tests, you are
doing TDD.

Now, as I have already mentioned a few times in this thread, I have a
friend who works for a aeronautical testing company. They are called
in to perform third-party independent verification of tests and test
results for flight systems. When flight systems are designed, their
complete behaviour is specified up front. The code and the tests are
written and then when all of the tests pass, the code is handed over
to the third-party folks for verification.

You can argue that this isn't TDD, and I wouldn't argue the point too
hard, but the basic philosophy is compatible. They think carefully
about what they want, they define the desired behaviour including what
the tests should test and then the developers get to work and then
there is another round where the third-party verification provides
feedback on the tests and how well they satisfy the original
requirements. Hmmmm, that sounds like something I've seen around here.
:-)

Quality is caring. http://simonpeter. org/technology/ writings/ thirdlaw. html

Without caring, even someone who is mandated to use TDD is going to
churn out Sierra Hotel 1 Tango. I've seen it done. At my previous
employer, unit tests were mandated, so some developers created unit
tests but never made any assertions about expected results. Naturally
the tests passed, because they never actually tested anything and
therefore could never fail.

While I'm fully in favour of TDD, without caring, TDD cannot work.
Without caring, non-TDD development techniques can't work either.
Without caring, even the aeronautical testing won't work.

If you do care about quality, I assert (pun intended) that TDD is the
most effective converter of caring into software quality.

Simon

--
www.simonpeter. org

On 8/11/06, Brett L. Schuchert <schuchert@yahoo. com> wrote:

> >> From: Simon Chappell <simonpeterchappell@ gmail.com>
> >> religion. I'm sure it's possible to write code that is "good enough"
> >> without TDD, but it'll never be high quality.
>
> You just made a strong claim:
> Without TDD you'll never be high quality
>
> 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@ gmail.com>
> To: junit@yahoogroups. com
> 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/
 

[Cédric Beust ♔]

On 8/12/06, Simon Chappell <simonpeterchappell@...> wrote:
>
>
> Any developer who cares will do better work than one who doesn't. But
> I also suggest that a developer that cares and uses TDD will do better
> than one who cares and doesn't use TDD. I get suspicious when a
> programmer says that they care and yet they don't want to use TDD.
> Tell me again how not creating easily testable code increases quality?


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

--
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/12/06, Stephen Smith <steve@...> wrote:
>
> Cedric,
>
> Isn't a dangerous assumption that your users will be sufficiently
> competent/knowledgeable about your software to identify bugs?


Oh, that was certainly not the assumption I was working on.  When you ship
your code, you certainly hope there is no bug in it.  I was just responding
to the claim that "if you don't TDD your code, you don't know that it works"
by saying that  "there are plenty of ways to know that your code works, and
testing is only one of them" (and an imperfect one at that, as somebody
pointed out earlier in this thread).

Test cases are the only reliable indicator of code quality _and_ code
> reliability, and because they are automated gives me far greater
> confidence in the integrity of the code I write.


Absolutely.

If I'm asked to review some code and tests, I will sit down and read the
code, and asking whether this code was tested using TDD will give me very
little clue as to its quality.

Kent's argument has always worked for me - TDD when you can, think about
> it when you can't.


Agreed.  I think that saying "if you don't do TDD, you don't know that your
code works" is preposterous.

In my opinion, it's not as important to "test first" as it is to "test
soon", which sometimes means "first" and other times means "when you think
it's time".

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

[Brett L. Schuchert]

> In my opinion, it's not as important to "test first" as it is to "test
> soon", which sometimes means "first" and other times means "when you think
> it's time".

Well put Cédric.
 
I'd like to add to "test soon" --> "and often"

 
Tutorials and Articles
     http://schuchert.wikispaces.com/



----- Original Message ----
From: Cédric Beust ♔ <cbeust@...>
To: junit@...
Sent: Saturday, August 12, 2006 2:27:38 PM
Subject: Re: [junit] Re: Are you really using JUnit during your development?

On 8/12/06, Stephen Smith <steve@stephen- smith.co. uk> wrote:
>
> Cedric,
>
> Isn't a dangerous assumption that your users will be sufficiently
> competent/knowledge able about your software to identify bugs?

Oh, that was certainly not the assumption I was working on. When you ship
your code, you certainly hope there is no bug in it. I was just responding
to the claim that "if you don't TDD your code, you don't know that it works"
by saying that "there are plenty of ways to know that your code works, and
testing is only one of them" (and an imperfect one at that, as somebody
pointed out earlier in this thread).

Test cases are the only reliable indicator of code quality _and_ code
> reliability, and because they are automated gives me far greater
> confidence in the integrity of the code I write.

Absolutely.

If I'm asked to review some code and tests, I will sit down and read the
code, and asking whether this code was tested using TDD will give me very
little clue as to its quality.

Kent's argument has always worked for me - TDD when you can, think about
> it when you can't.

Agreed. I think that saying "if you don't do TDD, you don't know that your
code works" is preposterous.

In my opinion, it's not as important to "test first" as it is to "test
soon", which sometimes means "first" and other times means "when you think
it's time".

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

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


 

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





 
Yahoo! Groups Links

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

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

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

[Marvin D. Toll]

In support of Cedric's opinion ...

When working with teams, I use the term "test concurrent" (rather
than test first) to send the message that:

1) When writing functional code think about the test.

2) When writing test code think about the functionality.

3) The specific order may be less important than the effective
thinking.

_Marvin


--- In junit@..., "Cédric Beust â™" " <cbeust@...>
wrote:
 
> In my opinion, it's not as important to "test first" as it is
to "test
> soon", which sometimes means "first" and other times means "when
you think
> it's time".
>
> --
> Cédric
> http://testng.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/
 

[Ilja Preuss-2]

Marvin Toll schrieb:
> 3) The specific order may be less important than the effective
> thinking.
>  
Perhaps.

On the other hand, I feel that writing the tests first *does* result in
different code for me. So I'm inclined to think that there actually
might be some importance in the order.

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/
 

[cliftonccraig]

I'm intruiged as well as confused by this.

--- In junit@..., "Marvin Toll" <MarvinToll@...> wrote:

>
>
> In support of Cedric's opinion ...
>
> When working with teams, I use the term "test concurrent" (rather
> than test first) to send the message that:
>
> 1) When writing functional code think about the test.
>
> 2) When writing test code think about the functionality.
>
> 3) The specific order may be less important than the effective
> thinking.
>
> _Marvin

how can you think about a test which does not yet exist? I'm not
labeling this as impossible though I do think it sounds impractical.
When you write functional code it ought to be satisfying some
practical usage contract. If the contract does not exist then your
functional code becomes the definition of the contract. Putting a test
on pre existing code becomes an excercise in putting a contract on a
contract. In short your implementation quickly and easily becomes more
important than the usage. (That's always been my experience and unless
you're extremely lucky or extremely gifted I find it hard to see how
your results would differ.) When the implementation becomes more
important than the usage you comprimise usability because it becomes
difficult to throw away functional code. If you don't have a problem
throwing away code you've just written for the sake of a test (which
would likely indicate that the code you've written needs changing or
deleting) then I guess order isn't important. However it would seem
immediately obvious that writing that functional code first was a
waste of time since it just gets deleted anyway making it more
practical to write the test first.

On the inverse, writing the test first would garuantee a usable
interface where no time would be wasted on throw away code. What I'm
trying to say here is that the existance of a test is not nearly as
important as a good interface or an accurate definition of the usage
of a piece of code. The Test is the only place to define that and
without that you will most likely have a bunch of tests that are
brittle and highly dependant on the internals of the functional code.
These types of test add no value as they are difficult to maintain. If
you are lucky or knowledgeable enough to write functional code without
a test then you are lucky or knowledgeable enough to go completely
without the test. Writing the test would only slow development under
these scenarios unless I'm missing something obvious.





 
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/
 

[Joakim Ohlrogge]

>  how can you think about a test which does not yet exist?
Not that I don't think that it would be better to write the test first
but I guess the answer to your question would be "in the same way you
can write a test for code that does not yet exist".

>  However it would seem
>  immediately obvious that writing that functional code first was a
>  waste of time since it just gets deleted anyway making it more
>  practical to write the test first.

I'm not sure the code would have to be deleted or changed, maybe a
little. Even if I'm convinced though that it is not the best way to
produce code I still think that you can produce code that you are
happy with even if you retrofit the tests.
On the other hand, after using TDD and looking back on how it changed
the way of thinking and how much it aided/simplified my thought
process I don't see how I would /want/ to do that. I'm having much
more fun now, writing much better code than I used to do and I think I
do it with less effort.


>  These types of test add no value as they are difficult to maintain.

I think that you would miss out on the value of the tests /driving/
the design wich I think is a lot. I don't think that they have /no/
value.

>  Writing the test would only slow development under
>  these scenarios unless I'm missing something obvious.
I would agree to that to some degree, if you miss out on the driving
part of your tests them the argument that it takes more time because
you have to write twice as much code is  a lot more valid. (You miss
out on the thoughtprocess and the design that "falls out of your
tests").

I agree with a lot you wrote since I read it the way I wanted to read
it. Someone else that wanted to read it differently would perhaps
loose some of the good points you make since it seems a bit "binary"?

I don't know, just my two cents for what they might be worth...


 
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/15/06, Joakim Ohlrogge <joakim.ohlrogge@...> wrote:
>
> >  how can you think about a test which does not yet exist?
> Not that I don't think that it would be better to write the test first
> but I guess the answer to your question would be "in the same way you
> can write a test for code that does not yet exist".


That was probably the point that Clifton was trying to make:  doing so will
have you focus on the interface of your code to your test, instead of
thinking of the primary reason why you're writing this code:  to implement a
feature.

>  These types of test add no value as they are difficult to maintain.
>
> I think that you would miss out on the value of the tests /driving/
> the design wich I think is a lot.


Design driven by tests is not necessarily better than design driven by
careful thought from an experienced developer.

Between "Do the simplest thing that can possibly work" (i.e. make a concrete
class and get the test to pass as soon as possible) and "Use an interface
for future ease of testing and maintenance", I usually go for the latter
because in my experience, it leads to cleaner design.  This is one of the
many examples where test-driven design is sometimes the wrong thing to do.

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

[Simon Chappell]

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

> Design driven by tests is not necessarily better than design driven by
> careful thought from an experienced developer.

Do you intend to infer that tests are a substitute for careful
thought? I don't think you meant that, but it was the first thought
that came to my mind.

I like to think that I consider my tests carefully, so the combination
of thought and test first and then code must surely trump thought and
code, no?

> Between "Do the simplest thing that can possibly work" (i.e. make a concrete
> class and get the test to pass as soon as possible) and "Use an interface
> for future ease of testing and maintenance", I usually go for the latter
> because in my experience, it leads to cleaner design.  This is one of the
> many examples where test-driven design is sometimes the wrong thing to do.

Who said that a test has to be welded to only one class? TDD does not
preclude using interfaces. A test is more a matter of a programmer
thinking "how do I want to call to receive the desired
functionality?". The programmer might decide that an interface is
exactly what needs to be used to call the method, and the test would
reflect that. To satisfy that test, the programmer would then create a
couple of classes, one of which would be the interface that they
decided would be part of the calling signature. (Remember, TDD is not
XP, you don't have to follow YAGNI.)

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/
 

[Cédric Beust ♔]

On 8/15/06, Simon Chappell <simonpeterchappell@...> wrote:

>
> > Between "Do the simplest thing that can possibly work" (i.e. make a
> concrete
> > class and get the test to pass as soon as possible) and "Use an
> interface
> > for future ease of testing and maintenance", I usually go for the latter
> > because in my experience, it leads to cleaner design.  This is one of
> the
> > many examples where test-driven design is sometimes the wrong thing to
> do.
>
> Who said that a test has to be welded to only one class? TDD does not
> preclude using interfaces.

No, but sayings such as "Do the simplest thing that could possibly work" or
"You aren't gonna need it" imply it...  A bit tangential to TDD, admittedly.

Still, sometimes, I find that putting the emphasis on testing first can
sometimes impact the final interface of your solution adversely.  In other
words:  your code ends up being more test-friendly than caller-friendly.

A test is more a matter of a programmer
> thinking "how do I want to call to receive the desired
> functionality?". The programmer might decide that an interface is
> exactly what needs to be used to call the method, and the test would
> reflect that. To satisfy that test, the programmer would then create a
> couple of classes, one of which would be the interface that they
> decided would be part of the calling signature. (Remember, TDD is not
> XP, you don't have to follow YAGNI.)


Agreed,  I conflated both a bit in my previous statement, sorry about that.

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

[Simon Chappell]

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

> Still, sometimes, I find that putting the emphasis on testing first can
> sometimes impact the final interface of your solution adversely.  In other
> words:  your code ends up being more test-friendly than caller-friendly.

I find this an interesting observation, because I have found that I
get not only test-friendly classes (natch), but that the API (the
methods that I decide to create) are usually much more
caller-friendly.

Perhaps I'm selfish, but if I'm writing code that I'm going to call,
then I'm going to make it as easy for *me* to call as possible. This
is one of the big pluses for me. Now, being an eclectic fellow, what
works for me may be bizarre for my co-workers, but that's a separate
issue! ;-)

Do you have any specific examples in mind of a time when you made your
own life more difficult by creating an unusable API?

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/
 

[J. B. Rainsberger]

Cédric Beust ♔ wrote:

> Agreed. I think that saying "if you don't do TDD, you don't know that your
> code works" is preposterous.

Does anyone actually say this? Who? When? I know I don't.

> In my opinion, it's not as important to "test first" as it is to "test
> soon", which sometimes means "first" and other times means "when you think
> it's time".

Compared to what?

Compared to "test never", test soon is a good idea. Compared to "test
first", test soon is usually a bad idea. If I have the option of testing
first or testing soon, I will almost always test first.
--
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]

Marvin Toll wrote:

> 3) The specific order may be less important than the effective
> thinking.

...only for the intelligent, experienced practitioner. While learning,
testing first is probably more important, because it enables effective
thinking. I suppose that because I work with novices more than masterful
practitioners, I tend to think about this from the novice's perspective.
--
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/