StorySmith aims to make behavior driven development easy with no new attributes or asserts to learn. StorySmith aspires to achieve this by requiring developers to adhere to the following guidelines:

0. There is always a story whether it is strongly typed or created on the fly

  public class CalculatorStory:IStory
        {

            #region IStory Members

            public string AsA
            {
                get
                 {
                    return "calculator user";
                }
                set{}
            }
            public string IWantTo
            {
                get
                {
                    return "add and subtract";

                }
                set{}
            }
            public string SoThat
            {
                get
                {
                    return "I can do complex calculations";
                }
                set { }
            }

            #endregion
        }

1. Every story has 'given(s)', 'when(s)' and 'then(s)'

2. Each 'When' is represented by a class.

 [TestFixture]
            public class When_they_are_added
            {
                NumberThree number_three = new NumberThree();
                NumberFour number_four = new NumberFour();

3. Each 'When' class should have it's given(s) defined in exactly one method and the method should be called before the tests are run.

[SetUp]
                public void GivenTheseConditions()
                {
                    Behavior.For(new Story{AsA="calculator user", 
                                            IWantTo="add and subtract",SoThat="I can do   complex calculations"})
                            .Given(number_one).And(number_two);
                }

or

 [SetUp]
                public void GivenTheseConditions()
                {   
                    Behavior.For(new CalculatorStory()).Given(5," of value 5 ").And(10," of value 10 ");
                    
                }

4. Each 'Given' condition/entity/domain object should have a method decorated with a [Setup] if it needs to do some work before being used OR the 'Given' class has to implement the 'IGiven' interface OR the work can obviously be done in the constructor of the 'Given' class.

 public class NumberThree 
        {
            public int Value;
            [SetUp]
            public void DoWhatever()
            {
                Value = 3;
            }
        }

OR

        public class NumberFour  :IGiven
        {
             public int Value;
            
            public void DoWork()
            {
                Value = 4;
            }
        }

OR

 public class NumberFour
        {
             public int Value;
            
            public NumberFour()
            {
                Value = 4;
            }
        }

5. Each 'Then' has to be in it's own method and should assert exactly one thing.

[Test]
                public void the_result_should_be_seven()
                {

                    int expected = 7;
                    int actual = number_four.Value + number_three.Value;
                    Behavior.Should(() => Assert.AreEqual(expected, actual, "three + four = seven"));


                }

And lastly, the output is printed to console in this format:

As a calculator user, I want to add and subtract ,
 so that I can do complex calculations
Given NumberThree
 and NumberFour
	When they are added:
		the result should be seven

This is my distorted view of BDD and if it widely deviates from the following blog posts, let me know so that I can revisit my approach.

http://dannorth.net/introducing-bdd

http://www.code-magazine.com/article.aspx?quickid=0805061