BDD on Creatine

In an attempt to further understand BDD, I chose to revise the code from my previous post after receiving some amazing advice from two people I regard highly (Scott & JP). I should state that this is my interpretation of that advice. This may or may not be the direction they were trying to guide me towards.

   12 public class when_prompted_to_save_changes_to_the_project : concerns_for<SaveChangesView>

   13 {

   14     context c = () => { presenter = an<ISaveChangesPresenter>(); };

   15 

   16     after_the_sut_has_been_created after = () =>

   17                                                {

   18                                                    save_changes_window = sut;

   19                                                    save_changes_window.attach_to(presenter);

   20                                                };

   21 

   22     protected static ISaveChangesPresenter presenter;

   23     protected static SaveChangesView save_changes_window;

   24 }

   25 

   26 public class when_the_save_button_is_pressed : when_prompted_to_save_changes_to_the_project

   27 {

   28     it should_save_the_current_project = () => presenter.was_told_to(x => x.save());

   29 

   30     because b = () => save_changes_window.save_button.control_is(x => x.OnClick(new EventArgs()));

   31 }

   32 

   33 public class when_the_cancel_button_is_pressed : when_prompted_to_save_changes_to_the_project

   34 {

   35     it should_not_continue_processing_the_previous_action = () => presenter.was_told_to(x => x.cancel());

   36 

   37     because b = () => save_changes_window.cancel_button.control_is(x => x.OnClick(new EventArgs()));

   38 }

   39 

   40 public class when_the_do_not_save_button_is_pressed : when_prompted_to_save_changes_to_the_project

   41 {

   42     it should_not_save_the_project = () => presenter.was_told_to(x => x.dont_save());

   43 

   44     because b = () => save_changes_window.do_not_save_button.control_is(x => x.OnClick(new EventArgs()));

   45 }

 

I hope this is slightly more soluble, then my previous post.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Mo Khan

mO, is just a kid who's excited about writing software. He's a student of his profession, and just wants to share his thoughts on software development.
This entry was posted in TDD, Windows Forms. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

3 Responses to BDD on Creatine

  1. Rob Scott says:

    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.

  2. huey says:

    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.

  3. Rob says:

    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.