quality@glassfish.java.net

Re: Fwd: [Issue 11388] [other] [embedded] Unable to get basic unit test working in Maven

From: Wouter van Reeven <wouter_at_van.reeven.nl>
Date: Wed, 6 Jan 2010 11:02:25 +0100

Hi,


To add to the excellent description that Richard has written: if after
the bridge has completed and is in production a request is made to add
lanes to also allow bicycles to cross, it is far easier to add the lanes
by extending the test cases you have produced.

Also, if some of the specs that already have been implemented, say the
amount of cars, changes it is more straightforward to change the specs
without the bridge come tumbling down.


Wouter

On Wed, Jan 06, 2010 at 11:50:52AM +0200, Richard Kolb wrote:
>
> Hi Judy
>
> 2010/1/6 Judy Tang <Judy.J.Tang_at_sun.com>
>
> You are doing so many things, supper man :-)
>
>
> Thanks , trying hard:)
>
>
>
>
> May be when you have time you could share with us your experience and
> result with TDD? In what way it helps you to write a high quality code.
> Some examples
> would be good to show when you do the TDD you can catch the bug, if you
> don't you may miss the bug. It is no hurry, only when you got time.
>
>
> But it's even more than just testing. It forces the developer to think before
> writing code.
>
> So if you are designing a bridge :
> Think about how many cars will carry, say 30 per minute
> Think about the wind speeds, say max 100 km/h
> Think about how many lanes are under the bridge.
> Then build the bridge, one part at a time and make sure it complies to the
> above.
>
> Instead of :
> Build a bridge
> Find out the bridge can handle the cars, so add cross beams two weeks before
> the bridge opens
> 10 years later the wind comes up, and the bridge falls down
> And the bridge needs more lanes a year down line, so it costs more money in the
> end.
>
>
>
>
> Test-driven development (TDD) is a software development technique that
> relies on the repetition of a very short development cycle: First the
> developer writes a failing automated test case that defines a desired
> improvement or new function, then produces code to pass that test and
> finally refactors the new code to acceptable standards
>
>
> Yes, is sounds a bit strange at first, but it saves time, improves quality and
> avoids silly bugs being introduced. :)
>
> regards
> Richard
>
>

-- 
Veel shit is mest voor de toekomst.
[Unknown Source]
Skype: wvreeven
Facebook: wvreeven
Twitter: wvreeven