Comments on: Test Driven Development vs "Plain Old Unit Testing" http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html Best practices for your goals Tue, 07 Feb 2012 08:29:47 -0500 hourly 1 http://wordpress.org/?v=3.3.1 By: 每周链接 #56 | Daniel Teng's Blog http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-30879 每周链接 #56 | Daniel Teng's Blog Tue, 20 Dec 2011 16:38:26 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-30879 [...] Neal Ford的工程类的文章和Workshop 代码怎么能这么烂 测试驱动开发 vs. 老式单元测试 [...] [...] Neal Ford的工程类的文章和Workshop 代码怎么能这么烂 测试驱动开发 vs. 老式单元测试 [...]

]]> By: Mark Levison http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-784 Mark Levison Fri, 23 Apr 2010 00:57:19 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-784 Joe - I approved your comment but don't you think it courteous to use a real name and email? As to communism its clear it wouldn't even work well in theory, if you think about its the waterfall of politics/economics: Central Planning, 5 yr plans etc. Joe – I approved your comment but don’t you think it courteous to use a real name and email?

As to communism its clear it wouldn’t even work well in theory, if you think about its the waterfall of politics/economics: Central Planning, 5 yr plans etc.

]]> By: Joe http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-782 Joe Fri, 23 Apr 2010 00:00:51 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-782 Micheal, excellent observation: "TDD is beautiful in theory same as Communism is but it all breaks down in practice." Micheal, excellent observation: “TDD is beautiful in theory same as Communism is but it all breaks down in practice.”

]]> By: Mark Levison http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-633 Mark Levison Tue, 13 Apr 2010 16:18:35 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-633 Micheal - first of all thanks for taking the time to comment. You're right a weak developer who isn't interested in improving their code quality will still produce crappy code. In fact a better way of saying it - you can TDD crap. Here's the thing if I'm coaching your team then one of our goals will be to help improve the code quality. From my own experience I can only say that I do see the difference when I write the tests first - it forces me to stay focused and simplify the code. I don't worry about the cases I'm not testing for yet and often they turn to be irrelevant. Perhaps you don't have the same experience. You say that TDD has too many loopholes where its not feasible and cost effective - I'm not sure what you mean. What are these cases? If your already doing POUT, why won't TDD work? I'm sorry that you've found TDD working for you - I suggest only you consider trying it again, perhaps using Coding Katas or <a href="http://agilepainrelief.com/notesfromatooluser/2008/10/tdd-randori-workshop.html" rel="nofollow">Coding Dojos</a>. Perhaps it won't work for you - but remember at the core of Agile we keep an open mind. Micheal – first of all thanks for taking the time to comment. You’re right a weak developer who isn’t interested in improving their code quality will still produce crappy code. In fact a better way of saying it – you can TDD crap. Here’s the thing if I’m coaching your team then one of our goals will be to help improve the code quality.

From my own experience I can only say that I do see the difference when I write the tests first – it forces me to stay focused and simplify the code. I don’t worry about the cases I’m not testing for yet and often they turn to be irrelevant. Perhaps you don’t have the same experience.

You say that TDD has too many loopholes where its not feasible and cost effective – I’m not sure what you mean. What are these cases? If your already doing POUT, why won’t TDD work?

I’m sorry that you’ve found TDD working for you – I suggest only you consider trying it again, perhaps using Coding Katas or Coding Dojos. Perhaps it won’t work for you – but remember at the core of Agile we keep an open mind.

]]> By: Micheal http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-626 Micheal Tue, 13 Apr 2010 15:11:00 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-626 Hi, I think TDD vs POUT is a case of chicken or egg, what's the big difference when you write the test? Yes I heard that it's about design and not testing(or both) but really what difference does it make if you design the old fashioned way(prototyping, etc.) or the new flashy way TDD? Cleaner code, fewer bugs, etc.? Well any code is only as good as the developer writing it, and tests can go bad too and paint you're design in a corner if you make too many false assumptions. TDD is beautiful in theory same as Communism is but it all breaks down in practice. There are simply too many loopholes where TDD is not feasible or not cost effective and the definiton of it is all or nothing so it ends up with nothing or a bloated unmaintainable horde of test cases that prove nothing of relevance. Hi,

I think TDD vs POUT is a case of chicken or egg, what’s the big difference when you write the test? Yes I heard that it’s about design and not testing(or both) but really what difference does it make if you design the old fashioned way(prototyping, etc.) or the new flashy way TDD? Cleaner code, fewer bugs, etc.? Well any code is only as good as the developer writing it, and tests can go bad too and paint you’re design in a corner if you make too many false assumptions. TDD is beautiful in theory same as Communism is but it all breaks down in practice. There are simply too many loopholes where TDD is not feasible or not cost effective and the definiton of it is all or nothing so it ends up with nothing or a bloated unmaintainable horde of test cases that prove nothing of relevance.

]]> By: Troy DeMonbreun http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-184 Troy DeMonbreun Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-184 I have encountered many objections to TDD in the blogosphere. Few admit that TDD is "too hard" (after all, there is one's ego to protect), but many admit that TDD introduces a significant overhead that they are unwilling/hesitant to adopt. It is hard to know whether all of those that are wary of implementing TDD would also be weary of implementing some degree of Unit Testing, be it test-first, test-last, etc., because most pro-TDD articles do not focus on the value of Unit Testing only. Personally, I do see value in Test-First design (http://blog.troyd.net/Test%2bSupported%2bDevelopment%2bTSD%2bIs%2bNot%2bTest%2bDriven%2bDevelopment%2bTDD.aspx), but I think many potential unit testers may be throwing out the baby with the bathwater. I have encountered many objections to TDD in the blogosphere. Few admit that TDD is “too hard” (after all, there is one’s ego to protect), but many admit that TDD introduces a significant overhead that they are unwilling/hesitant to adopt. It is hard to know whether all of those that are wary of implementing TDD would also be weary of implementing some degree of Unit Testing, be it test-first, test-last, etc., because most pro-TDD articles do not focus on the value of Unit Testing only.

Personally, I do see value in Test-First design
(http://blog.troyd.net/Test%2bSupported%2bDevelopment%2bTSD%2bIs%2bNot%2bTest%2bDriven%2bDevelopment%2bTDD.aspx), but I think many potential unit testers may be throwing out the baby with the bathwater.

]]> By: Troy DeMonbreun http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-185 Troy DeMonbreun Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-185 Here's the URL again (the RegEx parser was a little too hungry): http://blog.troyd.net/Test%2bSupported%2bDevelopment%2bTSD%2bIs%2bNot%2bTest%2bDriven%2bDevelopment%2bTDD.aspx Here’s the URL again (the RegEx parser was a little too hungry):

http://blog.troyd.net/Test%2bSupported%2bDevelopment%2bTSD%2bIs%2bNot%2bTest%2bDriven%2bDevelopment%2bTDD.aspx

]]> By: Mario Gleichmann http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-186 Mario Gleichmann Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-186 Nice post! You may want to take a look at http://www.infoq.com/news/2008/02/unit_tests_forests_n_trees for further ruminations on that topic. Greetings Mario Nice post!

You may want to take a look at

http://www.infoq.com/news/2008/02/unit_tests_forests_n_trees

for further ruminations on that topic.

Greetings

Mario

]]> By: Franco http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-187 Franco Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-187 I think that the problem could not the opposition between TDD and unit testing, but the lack of unit testing activity in the first place. You could find some hard data on test driven development and unit testing on * TDD Survey Results by Stelligent (2007) http://www.stelligent.com/pdf/TDDSurvey.pdf * Unit Testing: Can You Repeat Please? http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest I think that the problem could not the opposition between TDD and unit testing, but the lack of unit testing activity in the first place. You could find some hard data on test driven development and unit testing on
* TDD Survey Results by Stelligent (2007)
http://www.stelligent.com/pdf/TDDSurvey.pdf
* Unit Testing: Can You Repeat Please?
http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest

]]> By: Jeff Langr http://agilepainrelief.com/notesfromatooluser/2008/02/test-driven-dev.html/comment-page-1#comment-188 Jeff Langr Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/02/test-driven-dev/#comment-188 I personally think TAD (test-after development) is largely a waste of time. http://langrsoft.com/blog/2008/07/realities-of-test-after-development-aka.html I personally think TAD (test-after development) is largely a waste of time.

http://langrsoft.com/blog/2008/07/realities-of-test-after-development-aka.html

]]>