Quote:
Originally Posted by tyler_cracker
i think the argument is that it's never worth it to skip tests if you care at all about quality and/or maintainability. tdd actually saves time in the relatively near term by making the addition of new features (and the refactoring required to add those features) faster as well as safer. after-the-fact QA is not and will never give you the same level of quality as having every line of your code under test.
|
I've worked on two main types of programs in my career: 1) web sites with very rich user interactions and 2) data processing programs where the user has little to no input.
If we're talking about programs like 1) I strongly disagree with the two bolded sections above. Writing and maintaining tests for the front end can be a massive time suck - especially when you're supporting browsers from IE 6 to the latest Chrome. If we're talking about programs like 2) we're almost certainly in agreement.
On top of that, it's easy to get decent QA staff for manual testing that cost 1/3 to 1/4 of the cost of Devs.
Quote:
Originally Posted by tyler_cracker
i do think that the the tdd practitioners' position is sufficiently strong that if you are going to claim your case is an exception to the rule, you should have a good reason for it. i dont think that "it takes too long" or "it's too hard" are good reasons. (not ascribing either of those excuses to you shabby.)
|
Are there any good studies backing up their position? I've never seen any (and I've never really looked).
Quote:
Originally Posted by tyler_cracker
expensive to write/maintain tests sound like a separate problem  . |
True. But I've never seen easy to write/maintain front end tests for complex web sites.
Quote:
Originally Posted by tyler_cracker
were you pairing with one person all the time or with different people? what kind of software? any examples of giant wastes of time?
|
There were two of us as in-house developers and we were working with a team of 4 contractors. The 6 of us switched partners fairly equally. We were working on a fairly complex (from the UI perspective) web application.
A giant waste of time for me is to have two people build the shell of a new page. Or adding a field to a db table and pushing that data through the system to the front end. Or fixing a configuration problem on a machine (I remember one day two of us spending half an hour waiting for something to download...). There's a certain amount of boilerplate work that just doesn't require two people to do when building a Java website.
Quote:
Originally Posted by tyler_cracker
how many qa cycles does it take before you break even on those 8 hours, even just for testing that feature? how expensive is it when that feature has a bug that no one notices because it's so rarely used? if the feature is truly rarely used, can you just get rid of it?
|
I agree, all of these questions are important. I just don't agree that its obvious that the answers point to manual QA not being the answer.
Quote:
Originally Posted by tyler_cracker
i do think there is philosophical and even practical value in taking the 100% stance. for one thing, if your underlying philosophy is "yeah this is great... 90% of the time" then people are going to constantly claim that their code is in that 10% -- more excuses for not following the best practice.
|
I do agree with this. But I think there are ways around it. For example following a simple code review process for all check-ins gets you a lot of the same benefits as pair programming, without wasting as much time time, and also ensures that the proper things are unit tested (while also distributing knowledge of the code base and proper design techniques and thus speeding up future development).
Two Plus Two
Linear Mode
