Comments on: BDD on Creatine http://lostechies.com/mokhan/2009/03/12/bdd-on-creatine/ Just another LosTechies site Tue, 12 May 2009 07:06:21 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Rob http://lostechies.com/mokhan/2009/03/12/bdd-on-creatine/#comment-54 Rob Fri, 13 Mar 2009 17:41:10 +0000 /blogs/mokhan/archive/2009/03/12/bdd-on-creatine.aspx#comment-54 It's not that I couldn't determine what the intent was ... It's that it took more effort to grock the intent (and whether the test was testing that) than I felt it should -- and I'm at least somewhat familiar with (as in, I've written code using them) all of the different techniques being used in the example. YMMV. It’s not that I couldn’t determine what the intent was … It’s that it took more effort to grock the intent (and whether the test was testing that) than I felt it should — and I’m at least somewhat familiar with (as in, I’ve written code using them) all of the different techniques being used in the example.

YMMV.

]]> By: huey http://lostechies.com/mokhan/2009/03/12/bdd-on-creatine/#comment-53 huey Fri, 13 Mar 2009 15:17:30 +0000 /blogs/mokhan/archive/2009/03/12/bdd-on-creatine.aspx#comment-53 I don't know ... When prompted to save changes for the save changes view, when the save button is pressed it should save the current project When prompted to save changes for the save changes view, when the cancel button is pressed it should not continue processing the previous action When prompted to save changes for the save changes view, when the do not save button is pressed it should not save the current project ... that seems like defining behavioral specifications? I can't begin to discuss what is going on in the code (its above me conceptually) but the specification seems clear. I don’t know …

When prompted to save changes for the save changes view, when the save button is pressed it should save the current project

When prompted to save changes for the save changes view, when the cancel button is pressed it should not continue processing the previous action

When prompted to save changes for the save changes view, when the do not save button is pressed it should not save the current project

… that seems like defining behavioral specifications?

I can’t begin to discuss what is going on in the code (its above me conceptually) but the specification seems clear.

]]> By: Rob Scott http://lostechies.com/mokhan/2009/03/12/bdd-on-creatine/#comment-52 Rob Scott Fri, 13 Mar 2009 14:39:26 +0000 /blogs/mokhan/archive/2009/03/12/bdd-on-creatine.aspx#comment-52 Step away from the performance enhancing substances. They'll make your intent shrivel up and your tests turn yellow. More seriously, do you think this formulation makes the intent of your test / specification clearer to the reader (which I think is a main goal of test as behavioral specification)? I have to admit I struggled with understanding what was going on here. I don't think it's the BDD approach or the "use base class for context and derived classes for actions" idiom or the use of lambdas or the slightly awkward method names or the reliance on underscore naming that makes me scratch my head -- rather I think it's the piling on of all of those things together (i.e., the syntactic density) that makes my head hurt. What I was initially reminded of was C programmers who took delight in seeing just how many features they could cram into a single line of code. They often sacrificed clarity on the alter of conciseness. I suspect that you either a) have another step of refactoring to do, or b) a step of refactoring to undo, if you want to help the readers of your specification. I'm interested to see where you go with it. Step away from the performance enhancing substances. They’ll make your intent shrivel up and your tests turn yellow.

More seriously, do you think this formulation makes the intent of your test / specification clearer to the reader (which I think is a main goal of test as behavioral specification)?

I have to admit I struggled with understanding what was going on here. I don’t think it’s the BDD approach or the “use base class for context and derived classes for actions” idiom or the use of lambdas or the slightly awkward method names or the reliance on underscore naming that makes me scratch my head — rather I think it’s the piling on of all of those things together (i.e., the syntactic density) that makes my head hurt.

What I was initially reminded of was C programmers who took delight in seeing just how many features they could cram into a single line of code. They often sacrificed clarity on the alter of conciseness.

I suspect that you either a) have another step of refactoring to do, or b) a step of refactoring to undo, if you want to help the readers of your specification.

I’m interested to see where you go with it.

]]>