Robert Watkins wrote:
> 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.
Why do you say that? I recently deployed Emma (Java coverage) in our build
file for one component, making it both fast and easy for developers to get
coverage data. It's trivial for the developers to run, and it creates a good
target for them when doing after-the-fact unit testing. (This isn't an XP or
TDD shop - yet.)
In traditional development, most developers find it difficult to unit test
their own code, or to know when their tests are good enough. It becomes
frustrating for them because they're not used to thinking that way, and can't
predict when they'll be done because they don't have a good definition of
"done" for unit tests on existing code. Making it easy for developers to use
coverage tools solves these problems, by giving them a much more concrete
definition of being done. The developers are happier and the unit tests are
likely better than they would have been had they been left to write them with
no coverage tools.
Gary
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/
