David Newton wrote:I was thinking more along the lines of providing at least a tiny little hint as to the position instead of making people dig for it.
David Newton wrote:Seems like a tad more information would be in order, no?!
Originally posted by Cameron McKenzie:
As a lead developer, or heaven forbid, a project manager, I have seen much greater productivity out of my fellow developers when doing pair programming, even when they don't like it. My personal experience is that it works, and it makes developers more productive.
Originally posted by Jeanne Boyarsky:
First, a big thanks to Lasse Koskela for being here to promote the book Test Driven.
The winners are:
Please send your snail mail address to bookpromotion AT javaranch DOT com. To ensure the quickest response, please provide the following:
Your name (first and last - preferably the one you use on Javaranch)
Also, please include the following as the subject of your Email.
Book Promo Winner - Test Driven - Tuesday, September 25th 2007
As noted in the Book Promotion Eligibility Requirements and Legal type stuff, the winners have 8 days to submit their information.
Thanks and congrats to all the winners.
Originally posted by Jeff Langr:
I've written a bit about why TDD can help you go faster, using anecdotal claims, at both informit.com and developer.com. I've not seen any real research on this. The problem is that it's not very easy to take into account all the things that TDD impacts:
- time spent comprehending existing code
- ability to make changes on brittle or rigid code
- ability to sustain software over longer periods of time
- ability to accommodate changing requirements over time
- time spent debugging (or, money spent on help desk staffing, or on lost customers)
- defect rates
Many of these elements could be lumped into "quality of design."
I'm not saying that TDD is the best solution to all these challenges, but the benefits I've seen it provide in these areas is to me more than worth any slight additional initial coding effort.
From a pure coding standpoint, I've found that having tests allows me to "just code" faster, particularly once the system is past the initial "building block" phase. The ability to refactor means that I'm more likely to build tiny reusable methods and classes, which in turn improve my speed with respect to writing additional code.
Originally posted by bob philbin:
One application I've written demands a great deal of database interaction, and I've not found any good way to use ATDD because of that. It seems like I'll have to write way too much code just populating tables for a given test and thus embedding new sources of error. Does your C6 (or other parts of your book) cover this? Do you have suggestions for db-intensive ATDD?
Originally posted by mahmoud allam:
How TDD affect the testing phase in the SW life cycle?Does we need any testing if we use TDD?