<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Why I don&#8217;t use TDD or BDD</title>
	<atom:link href="http://blog.kangasbros.fi/?feed=rss2&#038;p=30" rel="self" type="application/rss+xml" />
	<link>http://blog.kangasbros.fi/?p=30</link>
	<description>Blog about software development and life-style entrepreneurship</description>
	<lastBuildDate>Wed, 16 May 2012 16:13:22 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: batman arkham city harley quinns revenge pre order</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-2997</link>
		<dc:creator>batman arkham city harley quinns revenge pre order</dc:creator>
		<pubDate>Wed, 16 May 2012 16:13:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-2997</guid>
		<description>Woah this blog is wonderful i love reading your posts. Keep up the great work! You already know, lots of people are looking around for this info, you can aid them greatly.</description>
		<content:encoded><![CDATA[<p>Woah this blog is wonderful i love reading your posts. Keep up the great work! You already know, lots of people are looking around for this info, you can aid them greatly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: websites to learn spanish students</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-2988</link>
		<dc:creator>websites to learn spanish students</dc:creator>
		<pubDate>Fri, 27 Apr 2012 13:59:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-2988</guid>
		<description>&lt;strong&gt;websites to learn spanish students...&lt;/strong&gt;

Why I dont use TDD or BDD « Kangas Bros. Innovations Blog...</description>
		<content:encoded><![CDATA[<p><strong>websites to learn spanish students&#8230;</strong></p>
<p>Why I dont use TDD or BDD « Kangas Bros. Innovations Blog&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: I am taking the Internet seriously now. I am retired and can dive into it. There are a lot of topics on the Internet and I am reading on many of those and commenting. I think that you have to put some attention on a blog to bring it above the dry and bori</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-2885</link>
		<dc:creator>I am taking the Internet seriously now. I am retired and can dive into it. There are a lot of topics on the Internet and I am reading on many of those and commenting. I think that you have to put some attention on a blog to bring it above the dry and bori</dc:creator>
		<pubDate>Mon, 05 Mar 2012 07:53:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-2885</guid>
		<description>&lt;strong&gt;I am taking the Internet seriously now. I am retired and can dive into it. There are a lot of topics on the Internet and I am reading on many of those and commenting. I think that you have to put some attention on a blog to bring it above the dry and...&lt;/strong&gt;

[...]Why I don&#8217;t use TDD or BDD &#171; Kangas Bros. Innovations Blog[...]...</description>
		<content:encoded><![CDATA[<p><strong>I am taking the Internet seriously now. I am retired and can dive into it. There are a lot of topics on the Internet and I am reading on many of those and commenting. I think that you have to put some attention on a blog to bring it above the dry and&#8230;</strong></p>
<p>[...]Why I don&#8217;t use TDD or BDD &laquo; Kangas Bros. Innovations Blog[...]&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: I am taking the Internet seriously now. I am retired and can dive into it. There is quite a rich diversity of information in blogs so I am getting involved and commenting. I think that you have to put some attention on a blog to bring it above the dry and</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-2883</link>
		<dc:creator>I am taking the Internet seriously now. I am retired and can dive into it. There is quite a rich diversity of information in blogs so I am getting involved and commenting. I think that you have to put some attention on a blog to bring it above the dry and</dc:creator>
		<pubDate>Mon, 05 Mar 2012 07:38:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-2883</guid>
		<description>&lt;strong&gt;I am taking the Internet seriously now. I am retired and can dive into it. There is quite a rich diversity of information in blogs so I am getting involved and commenting. I think that you have to put some attention on a blog to bring it above the dr...&lt;/strong&gt;

[...]Why I don&#8217;t use TDD or BDD &#171; Kangas Bros. Innovations Blog[...]...</description>
		<content:encoded><![CDATA[<p><strong>I am taking the Internet seriously now. I am retired and can dive into it. There is quite a rich diversity of information in blogs so I am getting involved and commenting. I think that you have to put some attention on a blog to bring it above the dr&#8230;</strong></p>
<p>[...]Why I don&#8217;t use TDD or BDD &laquo; Kangas Bros. Innovations Blog[...]&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BDD: Links, News and Resources (1) &#171; Angel &#8220;Java&#8221; Lopez on Blog</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-2623</link>
		<dc:creator>BDD: Links, News and Resources (1) &#171; Angel &#8220;Java&#8221; Lopez on Blog</dc:creator>
		<pubDate>Tue, 29 Nov 2011 09:36:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-2623</guid>
		<description>[...] Why I don’t use TDD or BDD http://blog.kangasbros.fi/?p=30 [...]</description>
		<content:encoded><![CDATA[<p>[...] Why I don’t use TDD or BDD <a href="http://blog.kangasbros.fi/?p=30" rel="nofollow">http://blog.kangasbros.fi/?p=30</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erwin Engelsma</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-1915</link>
		<dc:creator>Erwin Engelsma</dc:creator>
		<pubDate>Mon, 13 Dec 2010 15:53:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-1915</guid>
		<description>TDD and Unit tests are not exactly the same thing. I do not really believe in TDD. It is much better to start of with a proper design that has been optimized for testing. In one fell swoop this also implies a better quality of your code. But still: it is then still pretty good practice to tests your units. But honestly: just designing the testcases already brings to light alot of thinking errors in the design and code, in my experience.</description>
		<content:encoded><![CDATA[<p>TDD and Unit tests are not exactly the same thing. I do not really believe in TDD. It is much better to start of with a proper design that has been optimized for testing. In one fell swoop this also implies a better quality of your code. But still: it is then still pretty good practice to tests your units. But honestly: just designing the testcases already brings to light alot of thinking errors in the design and code, in my experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kelly</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-700</link>
		<dc:creator>Kelly</dc:creator>
		<pubDate>Mon, 13 Sep 2010 15:31:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-700</guid>
		<description>TDD is a discipline that requires quite a lot of practice to get right. The author did not, imho, spend enough time learning the technique to be able to make the claims that he does. At least he qualified his claims with &quot;I haven&#039;t done this long enough to know what I&#039;m talking about.&quot; 

I have personally used TDD on a one man project in a larger company to produce the most solid piece of code that company ever produced. That product is now shipping, and is serving a great number of people. Without TDD, I believe that project would have been much more unstable, like the other projects created at that company all were. Management thought I could go faster without writing tests, but I assure you I would have spent much more time debugging had I not been doing TDD.

No, TDD is not a silver bullet. In some cases, it is too much work to set up a suitable environment of mocks to make much sense. Things like device drivers and other smallish pieces of glue code are not very suitable to TDD. I am discouraged to see how difficult it is for many people to learn. It took a lot of effort for me to learn as I had nobody to learn from other than a mailing list. But I do believe in the technique for many types of projects.

When I was younger, I could keep more things in my head simultaneously. As I&#039;m now approaching 50, TDD is the &quot;wisdom&quot; that replaces the &quot;strength&quot; of my youth. For older programmers who are starting to feel the sharpness fade, I highly recommend TDD as a way of continuing to be highly productive without the mental gymnastics required to code with everything in your head.

The value of TDD IMHO is &quot;executable documentation&quot;. It makes old code easier to pick up and run with again. It is hard work. It takes discipline. Just as some programmers will never really grasp lamda functions, some will never catch the TDD fever. If you want to try it, do it on a new &quot;green field&quot; project where you have a year to learn the technique. TDD in a &quot;legacy&quot; environment is painful in the extreme. Or, if you have others to learn from in a pairing environment, take advantage of that to learn the technique.

Once you get that first failing test that you weren&#039;t expecting, you have that light bulb moment of &quot;When would I have found THAT ONE!!&quot; and you realize you are test infected. It saves an inordinate amount of time!</description>
		<content:encoded><![CDATA[<p>TDD is a discipline that requires quite a lot of practice to get right. The author did not, imho, spend enough time learning the technique to be able to make the claims that he does. At least he qualified his claims with &#8220;I haven&#8217;t done this long enough to know what I&#8217;m talking about.&#8221; </p>
<p>I have personally used TDD on a one man project in a larger company to produce the most solid piece of code that company ever produced. That product is now shipping, and is serving a great number of people. Without TDD, I believe that project would have been much more unstable, like the other projects created at that company all were. Management thought I could go faster without writing tests, but I assure you I would have spent much more time debugging had I not been doing TDD.</p>
<p>No, TDD is not a silver bullet. In some cases, it is too much work to set up a suitable environment of mocks to make much sense. Things like device drivers and other smallish pieces of glue code are not very suitable to TDD. I am discouraged to see how difficult it is for many people to learn. It took a lot of effort for me to learn as I had nobody to learn from other than a mailing list. But I do believe in the technique for many types of projects.</p>
<p>When I was younger, I could keep more things in my head simultaneously. As I&#8217;m now approaching 50, TDD is the &#8220;wisdom&#8221; that replaces the &#8220;strength&#8221; of my youth. For older programmers who are starting to feel the sharpness fade, I highly recommend TDD as a way of continuing to be highly productive without the mental gymnastics required to code with everything in your head.</p>
<p>The value of TDD IMHO is &#8220;executable documentation&#8221;. It makes old code easier to pick up and run with again. It is hard work. It takes discipline. Just as some programmers will never really grasp lamda functions, some will never catch the TDD fever. If you want to try it, do it on a new &#8220;green field&#8221; project where you have a year to learn the technique. TDD in a &#8220;legacy&#8221; environment is painful in the extreme. Or, if you have others to learn from in a pairing environment, take advantage of that to learn the technique.</p>
<p>Once you get that first failing test that you weren&#8217;t expecting, you have that light bulb moment of &#8220;When would I have found THAT ONE!!&#8221; and you realize you are test infected. It saves an inordinate amount of time!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Soe Moe</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-692</link>
		<dc:creator>Soe Moe</dc:creator>
		<pubDate>Wed, 08 Sep 2010 10:10:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-692</guid>
		<description>To do TDD right takes at least a year or more. And it is not to replace &quot;test&quot; or &quot;qa&quot;. The test suit is not written just for catching the bugs when you make changes. It is just sweet side-effect of TDD. The real value is it force you to think what you are trying to do before you actually write the production code. With BDD (just TDD done in right) will force you to ask questions to customer to prevent redoing things just because you don&#039;t know what customer want (you may think that the customer is stupid). And it will prevent you to write waste code, that is written because we, developers, think/guess that it is nice feature but customer never request. 

But.... TDD is not easy. It is the mindset/thinking process change so it requires time, hard-work and of course, believe. 

So.. don&#039;t use TDD if the project&#039;s success or failure doesn&#039;t matter to you.</description>
		<content:encoded><![CDATA[<p>To do TDD right takes at least a year or more. And it is not to replace &#8220;test&#8221; or &#8220;qa&#8221;. The test suit is not written just for catching the bugs when you make changes. It is just sweet side-effect of TDD. The real value is it force you to think what you are trying to do before you actually write the production code. With BDD (just TDD done in right) will force you to ask questions to customer to prevent redoing things just because you don&#8217;t know what customer want (you may think that the customer is stupid). And it will prevent you to write waste code, that is written because we, developers, think/guess that it is nice feature but customer never request. </p>
<p>But&#8230;. TDD is not easy. It is the mindset/thinking process change so it requires time, hard-work and of course, believe. </p>
<p>So.. don&#8217;t use TDD if the project&#8217;s success or failure doesn&#8217;t matter to you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean Cleetus</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-687</link>
		<dc:creator>Sean Cleetus</dc:creator>
		<pubDate>Wed, 08 Sep 2010 04:27:14 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-687</guid>
		<description>I would love to think otherwise, but using TDD for one person projects (which does not need maintanence???) is a complete waste of time. 

As someone pointed out earlier, it all depends on where you are using it. In a large organization where people are just exchange-able resources, it makes sense to ensure code base is not completely dependent on individuals and TDD plays an important role there. 
If the tests are written correctly and maintained along with product code base, it is not possible for a developer to break any existing features while implementing a new feature or fixing a bug.
It is true that effort/time requirements are tripled. But TDD ensures the best case that a feature once accepted by the QA team shall not break.</description>
		<content:encoded><![CDATA[<p>I would love to think otherwise, but using TDD for one person projects (which does not need maintanence???) is a complete waste of time. </p>
<p>As someone pointed out earlier, it all depends on where you are using it. In a large organization where people are just exchange-able resources, it makes sense to ensure code base is not completely dependent on individuals and TDD plays an important role there.<br />
If the tests are written correctly and maintained along with product code base, it is not possible for a developer to break any existing features while implementing a new feature or fixing a bug.<br />
It is true that effort/time requirements are tripled. But TDD ensures the best case that a feature once accepted by the QA team shall not break.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin</title>
		<link>http://blog.kangasbros.fi/?p=30&#038;cpage=1#comment-686</link>
		<dc:creator>Justin</dc:creator>
		<pubDate>Tue, 07 Sep 2010 18:23:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kangasbros.fi/?p=30#comment-686</guid>
		<description>At my company we had argued about TDD and testing in general for a while.  We decided to test the TDD theory.  We took a complex piece of business logic and had one developer who knew and loved TDD and one who hated the idea of testing and had each of them develop the business logic.

The developer who didn&#039;t like testing created a lot of the code, wrote println and assert statements to verify his assertions at various steps of the code, ran the code frequently and looked at the output.  He repeated the process until he was confident that it was right.

The developer who did TDD coded an assertion into a test and then wrote code to fulfill the assertion.  He then repeated the process, refactoring the code as he went until he was confident that it was right.

Both projects took about the same amount of time to complete.  Both worked well and accomplished the intended task.  The TDD code was only about 70% the length of the non-TDD code and the TDD code was cleaner and easier to read and understand.  The TDD code also ran about 10% faster when profiled.

Lastly the tests were a reusable artifact that would allow us to make changes to the system later if the business rules changed.

As I see it, you can write code without TDD or other unit tests, but if you can do it in the same amount of time, get faster, cleaner code, and have a test suite to boot, why would you choose not to do it?

I do understand that learning TDD takes some time, but it sounds to me like it&#039;s worth it.</description>
		<content:encoded><![CDATA[<p>At my company we had argued about TDD and testing in general for a while.  We decided to test the TDD theory.  We took a complex piece of business logic and had one developer who knew and loved TDD and one who hated the idea of testing and had each of them develop the business logic.</p>
<p>The developer who didn&#8217;t like testing created a lot of the code, wrote println and assert statements to verify his assertions at various steps of the code, ran the code frequently and looked at the output.  He repeated the process until he was confident that it was right.</p>
<p>The developer who did TDD coded an assertion into a test and then wrote code to fulfill the assertion.  He then repeated the process, refactoring the code as he went until he was confident that it was right.</p>
<p>Both projects took about the same amount of time to complete.  Both worked well and accomplished the intended task.  The TDD code was only about 70% the length of the non-TDD code and the TDD code was cleaner and easier to read and understand.  The TDD code also ran about 10% faster when profiled.</p>
<p>Lastly the tests were a reusable artifact that would allow us to make changes to the system later if the business rules changed.</p>
<p>As I see it, you can write code without TDD or other unit tests, but if you can do it in the same amount of time, get faster, cleaner code, and have a test suite to boot, why would you choose not to do it?</p>
<p>I do understand that learning TDD takes some time, but it sounds to me like it&#8217;s worth it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

