2010/1/6 Judy Tang <Judy.J.Tang_at_sun.com>
> Thanks Richard. This is a great example. Woulter also said he uses TDD.
> Would be interest to hear from more cats, fishes on TDD experience :-)
>
Me as well. Java-EE 6 should be simple and actually test driven development
makes it so easy.
Since the developer does not need to code, deploy, check, fix, deploy,fix,
add code, deploy , fix
> Does the initial development cycle becomes longer, how much longer? Any
> special tool for TDD?
>
Short answer I would be yes, longer. It is almost like writing a spec for
the code, but in the end it saves time. There are so many studies that prove
this.
There are lots tools for that. Like Junit and DBUnit and so many more. Junit
is built into NetBeans, Eclipse and Maven :)
Here is an example of a test I just wrote.
It checks that if I create a new customer, it indeed does get added
properly.
private StagingUtscustmerFacadeLocal getStagingUtscustmerFacadeLocal()
throws NamingException {
Context ic = c.getContext();
StagingUtscustmerFacadeLocal ejb = (StagingUtscustmerFacadeLocal)
ic.lookup("java:global/EnygmaEJBNB/StagingUtscustmerFacade");
return ejb;
}
@Test
public void create() throws NamingException {
int initialCount = getStagingUtscustmerFacadeLocal().count();
String randomString = getRandomString();
getStagingUtscustmerFacadeLocal().create(new
StagingUtscustmer(randomString));
int afterCount = getStagingUtscustmerFacadeLocal().count();
if (initialCount == afterCount) {
Assert.fail();
}
}
regards
Richard.
>
>
> 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<http://en.wikipedia.org/wiki/Software_development>technique that relies on the repetition of a very short development cycle:
>> First the developer writes a failing automated test case<http://en.wikipedia.org/wiki/Test_case>that defines a desired improvement or new function, then produces code to
>> pass that test and finally refactors<http://en.wikipedia.org/wiki/Code_refactoring>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
>
>
>
>