Comments on: The Joy of Behavior Driven Development (BDD), or, Re-writing Code in Asserts is Not Unit Testing http://enfranchisedmind.com/blog/posts/behavior-driven-development/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Enfranchised Mind » How Should I Burn My Free Time? http://enfranchisedmind.com/blog/posts/behavior-driven-development/#comment-34108 Enfranchised Mind » How Should I Burn My Free Time? Fri, 23 Jan 2009 16:00:06 +0000 http://enfranchisedmind.com/blog/?p=854#comment-34108 [...] how to extend EasyB — Although EasyB is the best BDD framework in the Java/Groovy sphere, it still has some substantial limitations that need to be [...] [...] how to extend EasyB — Although EasyB is the best BDD framework in the Java/Groovy sphere, it still has some substantial limitations that need to be [...]

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/behavior-driven-development/#comment-33874 Robert Fischer Fri, 21 Nov 2008 06:32:53 +0000 http://enfranchisedmind.com/blog/?p=854#comment-33874 One thing I'd like to note, because I'm not sure I made it clear -- it's not just that there is a pretty print-out of the states. What's important is that BDD is implying a structure to the testing that xUnit testing does not have, which directs the testing much more carefully and greatly improves clarity. In contrast to xUnit's tendency to act in terms of mimicking implementation, BDD forces the developer to at least speak in terms of proving out functionality. One thing I’d like to note, because I’m not sure I made it clear — it’s not just that there is a pretty print-out of the states. What’s important is that BDD is implying a structure to the testing that xUnit testing does not have, which directs the testing much more carefully and greatly improves clarity. In contrast to xUnit’s tendency to act in terms of mimicking implementation, BDD forces the developer to at least speak in terms of proving out functionality.

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/behavior-driven-development/#comment-33851 Robert Fischer Thu, 13 Nov 2008 00:05:41 +0000 http://enfranchisedmind.com/blog/?p=854#comment-33851 @James There's a big FAILED on the user output. For developers, there's a nice page with drill-downs that tell you what failed and at which point. Including stack trace, if that kind of thing rocks your world. @James

There’s a big FAILED on the user output. For developers, there’s a nice page with drill-downs that tell you what failed and at which point. Including stack trace, if that kind of thing rocks your world.

]]> By: James http://enfranchisedmind.com/blog/posts/behavior-driven-development/#comment-33848 James Wed, 12 Nov 2008 15:24:31 +0000 http://enfranchisedmind.com/blog/?p=854#comment-33848 Looks very interesting. Do you have an example of what the output looks like when the tests fail? The pass cases look very readable, but I'd be interested to see how easy it is to figure out what's broken when a test fails. Looks very interesting. Do you have an example of what the output looks like when the tests fail? The pass cases look very readable, but I’d be interested to see how easy it is to figure out what’s broken when a test fails.

]]> By: Matthew Taylor http://enfranchisedmind.com/blog/posts/behavior-driven-development/#comment-33840 Matthew Taylor Tue, 11 Nov 2008 21:17:58 +0000 http://enfranchisedmind.com/blog/?p=854#comment-33840 @ben If you do it right, most test code will be very verbose, but who cares? The more verbose the test, the better. Your production code tends to be more succinct, clearer, and -- oh by the way -- correct. And that is the goal. @ben If you do it right, most test code will be very verbose, but who cares? The more verbose the test, the better. Your production code tends to be more succinct, clearer, and — oh by the way — correct. And that is the goal.

]]>