Ron Jeffries wrote:
> Use of "many resources" will not make the tests better.
>
> Running them asynchronously is done because they take a long time.
> The fact that it takes a long time to know if you've done good work
> is the bug. Fix it.
I would posit that certain tests, by their very nature, have to take a long
time. Performance profiling and endurance tests come to mind. Also,
acceptance tests (which typically use the system in a deployed state, not
an abstracted one like unit tests) take longer to run, particularly if a
database is involved. Even if you stub out part of the infrastructure for
the acceptanace tests, you need to have at least some end-to-end tests to
ensure that everything does hang together.
I would also posit that certain QA practices, such as determining test
coverage levels, take more time than a developer wants to spend, and don't
make much sense for a developer to run anyway.
A layered build approach (which CruiseControl supports "out of the box")
makes a lot of sense in such a scenario. Does this describe every team? No.
Note that reducing build times is still important when using a build
server. The build status is feedback information; you do want it as soon as
possible.
Robert.
--
"Software is too expensive to build cheaply"
Robert Watkins http://twasink.net/ [EMAIL PROTECTED]
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
