JavaWorld
addict
Reged: 06/20/03
Posts: 482
|
|
Best practices for test-driven development
|
Anonymous
Unregistered
|
|
Haven't you guys used dynamic mock frameworks like JMock / EasyMock? These frameworks make stuff like preventing accidental method invocation a breeze. The latest version of JMock (via a CGLIB extension) can mock concrete classes too. Writing mocks is not as tedious as this article makes it out to be.
|
Funny
Unregistered
|
|
Haven't you guys heard of cost benifit analysis and the point of diminishing returns? Testing costs money, and not all bugs have equal costs....
I love the notes about pair programming. "the guy in the back got bored" or in other words 'pair programming is just a scam to feather bed work, and to prop up the incompetent'. But doing 'TDD gets both involved' should be read as 'doing useless low value work provides enough make work for the feather beded jobs to look valueable'.
Incompetence always looks for 'new techniques' to hide from admitting the truth.
|
Anonymous
Unregistered
|
|
Any methodology gives room for the lazy. "Agile" methodologies give you a better perspective from the programmer morale point of view, without deteriorating code quality. That's why those methodologies grow so fast.
You have anger problems, man... your response is non-justified and tipically passive-aggressive.
------
Quote:
Haven't you guys heard of cost benifit analysis and the point of diminishing returns? Testing costs money, and not all bugs have equal costs....
I love the notes about pair programming. "the guy in the back got bored" or in other words 'pair programming is just a scam to feather bed work, and to prop up the incompetent'. But doing 'TDD gets both involved' should be read as 'doing useless low value work provides enough make work for the feather beded jobs to look valueable'.
Incompetence always looks for 'new techniques' to hide from admitting the truth.
|
Unregistered
|
|
Quote:
Haven't you guys heard of cost benifit analysis and the point of diminishing returns? Testing costs money, and not all bugs have equal costs....
And all bugs are cheaper to find earlier than later.
Quote:
I love the notes about pair programming. "the guy in the back got bored" or in other words 'pair programming is just a scam to feather bed work, and to prop up the incompetent'. But doing 'TDD gets both involved' (etc....)
Pair programming is more tiring because there's a certain amount of peer pressure to focus on the task and perform. If you had been pair programming you wouldn't have been wasting time online ranting against practices you've never actually tried yourself.
-mj
http://www.danube.com
|
Acobar
Unregistered
|
|
I have to agree with the above poster. Without a doubt, TDD using Agile methodologies, including paired-programming is the way to go. Yes, it's very exhausting because of the level of engagement required by both parties far exceeds that which is needed if one is sitting in a cube doing the work alone.
After it's done, however, the code is far better tested, has less bugs, and the classes created are simpler, easier to understand, and are usually pretty small.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
