fuzzelogic Solutions

Hi All!
Since the last bdd sugar post, I’ve been using a slightly different layout on the bdd “style” tests. First off, maybe a little clarification is in order - to set the record straight. BDD - is a phase coined by Dan North and (in simplistic terms) uses a Given, When, Then grammer. The other grammer used is highlighted in the context specification style of writing these [tests]. At a high level both try to achieve the same thing of shifting the focus onto the behaviour of the system under development and to make this a design effort. Both also focus on a AAA style . There are differences, and (to me) both provide benefit.

Some terms that I’ll be using, and what they are intended to mean.
Context:   the bits that are setup and used within a particular story/feature/behaviour
Scenario : a condition/set of conditions that contribute to a scenario
Observation: the outcome of executing the Context  + Scenario.
If: the actual scenario / alternate path.
So what are the changes. Well, I’ve tried to bring the observation more into focus, and moving the context “lower” to not distract from what we want to achieve. here’s an example…

[Scenario][Context("when<transfering_money_between_accounts>")]
public class if_the_FROM_account_has_sufficient_funds : when<transfering_money_between_accounts>{
[Observation]
public void it_should_debit_the_amount_from_the_FROM_account_and_credit_it_to_the_TO_account(){
/// setup for the scenario....
/// observe the outcome..
  }

}

Thats cleared up the context, provided us a path to explore different scenarios and observe their outcomes. The only setting up we are doing at that point is for the change in the scenario. The actual context remains unchanged. Thats taken care of in the implementation of the when<transfering_money_between_accounts>. Here’s a sample of the context

 #region-[ Contexts ]-

        public class transfering_money_between_accounts : AccountManagerSpecs{
            public IMessageService message_service;
            public override void setup_the_context(){
                the_to_account = a_mock_of<IAccount>();
                message_service = a_mock_of<IMessageService>();
            }
            protected override IAccountManger create_the_system_undertest(){
                return new AccountManager(message_service);
            }

            public IAccount the_from_account;
            public IAccount the_to_account;
        }
        #endregion

BDD: Given when then
Implementing the given when then grammer we have the following

[Scenario][Context("when<transfering_money_between_accounts>")]
public class if_the_FROM_account_has_sufficient_funds : when<transfering_money_between_accounts>{
 [Observation]
 public void it_should_debit_the_amount_from_the_FROM_account_and_credit_it_to_the_TO_account(){
  Given(x => x.the_from_account = new Account(200))
   .When(x =>x.the_system_under_test.transfer(100,x.the_from_account, x.the_to_account))
      .Then(x => x.the_from_account.debit(100))
      .And(x =>x.the_to_account.was_told_to(y => y.credit(100)));
  }
}

Context Specification:
Implementing the context specification grammer we have the following

[Scenario][Context("when<transfering_money_between_accounts>")]
public class if_the_FROM_account_has_sufficient_funds : when<transfering_money_between_accounts>{
 [Observation]
 public void it_should_debit_the_amount_from_the_FROM_account_and_credit_it_to_the_TO_account(){
  If(x => x.the_from_account = new Account(200))
   .because(x =>x.the_system_under_test.transfer(100,x.the_from_account, x.the_to_account))
      .observer_that(x => x.the_from_account.debit(100))
      .observer_that(x =>x.the_to_account.was_told_to(y => y.credit(100)));
  }
}

For me, this moves the context slightly out of focus , and moves the scenario and observation more in focus. Is this better?? Well, I’m using it on a current project, and will let you know.

Hope that helps
Thanks
Zak

DevG / Isle of Man software developers group monthly meetings

I’m trying to schedule the next one of the S.O.L.I.D principles - the Liskov substitution principle (LSP) - for the 23rd September 2009. It should be at the same place (Dimension data-Isle of man) and for around the same time - start at 6:30pm

The actual presentation shouldn’t be too long, although based on the previous ones, the actual discussions could go on.

If there’s anything from previous presentations, my BDD testing style (or anything else) that you’d like to discuss, please let me know.

Hope that’s ok..

Thanks

Zak

A few design principles to get you going (which are in NO special order). In addition to the basic OO principles, here’s my pin up post on design principles to strive toward (I’ll add to this as we go along). 

• Hide details of the implementation: Code to contracts and not implementations. Contracts are either abstract classes or pure interfaces.
• Keep coupling to a minimum : a class can depend on native types (basic ints,bools etc) but should only depend on a select few peer classes. If the dependencies are high, consider this a smell and refactor to reduce the dependency. This can include creating new specialized types that are composed of the dependencies, but again this must be managed correctly.
• Maintain maximum cohesion: a class should focus on a single concept.
• Favour composition over inheritance: there’s a few different ways to get objects to collaborate – inheritance, composition, subscription through event handling.
• Adhere to the Open closed principle: an object should be opened for extension (able to extend its behaviour )but closed for modification (while extending the behaviour you should not modify its source code)
• Follow LSP where possible. Liskov Substitution principle: objects that have references to base types should be able to use derived types without knowing the difference. The basic concept behind polymorphism. TIP: design objects around behaviour and not data.
• Use Inversion of control / Dependency Inversion principle :a formal definition: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
• Employ the Interface Segregation principle: Objects should not be forced to depend on interfaces that they don’t use.
• Consider using the Law of Demeter : Only talk to your immediate friends, so the following would be considered a violation …
  • var payment= Client.Wallet.GetMoney(10.00);
  • This will be an interesting one to enforce if you plan on sticking to Domain driven design principles which suggest that you should get to entities through their aggregates.
• Encapsulate the variations: when encountering variants encapsulate those bits that vary and make them first class citizens.
• Consider using Factories for object creation.

The above are principles and guidelines and violating them in okay, but only if you understand why doing so is better than following them.

 Hope this helps!