<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Chris Pratt - Latest Comments in An Introduction to Behavior Driven Development</title><link>http://chrisdpratt.disqus.com/</link><description></description><language>en</language><lastBuildDate>Tue, 04 Sep 2007 11:00:45 -0000</lastBuildDate><item><title>Re: An Introduction to Behavior Driven Development</title><link>http://www.chrisdpratt.com/2007/09/03/an-introduction-to-behavior-driven-development/#comment-4969639</link><description>Thank you all for your comments. Sometimes what you write makes sense to you, but you come to find out that it doesn't necessarily make sense to others. This seems to be the case here.&lt;br&gt;&lt;br&gt;Dave Astels, the front-runner advocate of BDD, explains the difference between TDD and BDD thus: "BDD is what you're doing if you're doing TDD really well."&lt;br&gt;&lt;br&gt;I think I made too much out of the differences between the two methodologies, but they are really quite similar. The chief and primary difference between BDD and TDD is that of semantics.&lt;br&gt;&lt;br&gt;The goal in both methodologies is to test behavior rather than state. By that, I mean that we want our tests to be implementation independent. All my test should care about is that the functionality is there, not how that functionality works.&lt;br&gt;&lt;br&gt;And that is where the chief problem with TDD comes. Because of its test-based nomenclature, it's more tempting for people to test the bits and pieces of the application rather than the central functionality. BDD is a reformulation of TDD, using more behavior-specific nomenclature, based on the Sapir-Whorf theory that language influences behavior.&lt;br&gt;&lt;br&gt;In other words, all BDD does is remove the word 'test' from the playing field, so that it's easier to focus on the true purpose of TDD: specifying behavior.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">chrisdpratt</dc:creator><pubDate>Tue, 04 Sep 2007 11:00:45 -0000</pubDate></item><item><title>Re: An Introduction to Behavior Driven Development</title><link>http://www.chrisdpratt.com/2007/09/03/an-introduction-to-behavior-driven-development/#comment-4969638</link><description>I agree, with the first comment, I was expecting an "aha" moment (after which I would jump on to the BDD bandwagon :) - but what you have described sounds exactly like the unit tests I write.&lt;br&gt;&lt;br&gt;I would like to see something in real code, ideally compared side by side with a TDD approach - in order to be convinced that this is just not yet another "snake oil" concept.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Peter Thomas</dc:creator><pubDate>Tue, 04 Sep 2007 06:13:02 -0000</pubDate></item><item><title>Re: An Introduction to Behavior Driven Development</title><link>http://www.chrisdpratt.com/2007/09/03/an-introduction-to-behavior-driven-development/#comment-4969637</link><description>To me sounds like functional testing :)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dev</dc:creator><pubDate>Tue, 04 Sep 2007 05:25:06 -0000</pubDate></item><item><title>Re: An Introduction to Behavior Driven Development</title><link>http://www.chrisdpratt.com/2007/09/03/an-introduction-to-behavior-driven-development/#comment-4969636</link><description>This is the first time I hear about Behavior-driven development, but to me it sounds exactly like TDD - at least in the way I use TDD. I'm looking forward to your next post; comparing rSync with xUnit will probably help me chisel out  the differences.&lt;br&gt;Great post!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Hans-Eric Grönlund</dc:creator><pubDate>Tue, 04 Sep 2007 04:48:02 -0000</pubDate></item></channel></rss>