TDD is great because running all the tests ends up taking a very long time and producing large amounts of text, which gives you (the programmer) a great excuse for slacking off.
Name:
Anonymous2011-07-13 8:58
we all slack off from time to time.
the matter is: can we slack off with confidence?
Name:
Enterprise programmer2011-07-13 9:26
In my team of 3 programmers. TDD has helped us:
* We spend much less time debugging.
* We make less mistakes (there was a period when we made a LOT of mistakes... so much that the customer was getting angry, and that is BAD)
* We deliver faster
* We slack off a lot now :)
* We have much less trouble with new programmers now (we had 5 different programmers in the last 2 years)
* Documentation is easier to do now (we document directly in the code of our tests)
So, in retrospective, it helped us a lot. Mainly because it improved the quality of our software. But it was painful and difficult to convince the managers that those 2 (sometimes 1) days spent making the tests were worth the effort. It was painful to teach the other programmers to only run the tests for validation.
As for TDD for solo projects?
I don't know. It might work, but in my experience it does work on teams, and very well.
Name:
Anonymous2011-07-13 12:46
you know what's a better way to reduce bugs than TDD? writing more concise code.
TDD is a good idea I guess, but it's always advocated by C++/Java faggots. Pretty obvious why.
"There's bound to be stuff where this would have gone faster if we'd had unit tests or smaller modules or whatever. That all sounds great in principle. Given a leisurely development pace, that's certainly the way to go. But when you're looking at, "We've got to go from zero to done in six weeks," well, I can't do that unless I cut something out. And unit tests are not critical."
>>14
Yeah, 'cause Netscape only took 6 weeks to reach version 7, and was virtually bug free. Oh wait.
Name:
Anonymous2011-07-13 22:52
connect the dots la da dada
connect the dots la da dada
connect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dadaconnect the dots la da dada
connect the dots la da dada
Name:
Anonymous2011-07-13 23:44
13 July 2011
The US Government is due to establish a Federal Programming Administration (FPA) over the next few weeks. During this time, government officials will be screening individuals for administrative positions and will be laying the groundwork for guidelines which all software companies will soon be required to follow.
Under these guidelines, all computer code will be required to meet a level of quality. "Obviously, there is a lot of code in the market already," explains government technical expert Ryan Jennings. "Thus, the FPA will only screen software by a complaint-by-complaint basis." Jennings goes on to describe a couple of the guidelines. "In the future, programs will have to start up in less than a couple of seconds. The programs themselves have to be programmed in one of the many enterprise languages which are widespread in use, such as Java, VB.NET, and PHP. Remember, a positive user experience is everything here and the FPA will ensure that it happens."
US Congress is due to pass a set of laws in the future which will halt the distribution of computer software deemed "low-quality" by the FPA. According to Jennings, "The goal here is to lower and eventually eliminate the already high amount of poor quality software. Top issues in the agenda include the elimination of functional programming, a sub-par programming practice, and particularly open-source software. Open-source software is seen as destructive to the economy so we already have plans to ban its production." The screening process is estimated to be completed in a few days. "It's only a matter of time, but I'm certain this is going to work out. I really see a bright future in the computer industry."
Name:
Anonymous2011-07-14 0:57
>>14
True. And that's the hard part of TDD, to find time to create the tests and their support libraries.
TDD is still good. Good enough in the sense that is better to use it than not.
How TDD's born:
For all X being a good development practice, ``Hey, X is good and pretty natural to do, let's give it an enterprisey name, sell it as REVOLUTIONARY SCALABLE DEVELOPMENT STRATEGY and shove it down everyone's goddamned throat''
>>19
Yeah, and that pesky revision control religion is a nasty waste of time too.
TDD just happens to be a sane practice someone gave a name to. All you really need to do is create tests early on, and continue to maintain test coverage as the codebase grows. Knowing the moment you make a change whether or not you broke something will save you a lot of time.
TDD has actually helped me quite a bit. I thought I was good at mentally architecting software, but TDD greatly enhances my ``vision''. It's one thing to think in advance, and another to force yourself to deal with the interfaces you have not yet created, right away.
Also, it's undeniable that writing tests is fucking boring. I theorize that fluent assertions exist solely because they make testing looks cooler (sure, readability is important, but the vast majority of tests aren't even slightly complex). TDD gets rid of the bad parts before you get to the good stuff.
I am a man who always eats the salad before the yummy meat, and that's how I approach programming.