fuzzelogic Solutions

Hey all!
MSBuild is the build tool from Microsoft, and ships with the .net framework. Its got the advantage of having a decent build tool thats available on your dev, build, test and production server. This means that your build machine does not need the IDE installed (or anything else). Its XML based, and works by focusing on a Target which runs Task(s). There’s a bunch of predefined tasks, and its “pluggable”, so you can create tasks to do just about anything you want. Each target has a name, and a depends on targets attribute. The name attribute, well that’s easy enough. The dependsOnTargets attribute is a list of other targets that have to happen first, before “this” target runs its task(s).
Here’s a sample msbuild script. I’ve used this as a start off script for a couple projects.

For the above to work, I use a folder structure as follows…

solution folder structure

The build folder contains the build file, lib contains all 3rd party dlls, src(source) contains the source projects, tools contains the 3rd party tools used (nunit, etc).
The build folder also contains a batch/short cut to open a command prompt with the VS Tools assigned. Create a batch file (or short cut and in the target property) add   %comspec% /k “”c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat”" x86 .

biuld folder

Unfortunetly, nUnit tasks are not supported out the box. BUT… hey, its easy to get a task to support the nUnit-console. That’s what the
<UsingTask TaskName=”nUnitTask” AssemblyFile=”..\lib\Fuzzelogic.MsBuild.Tools.nUnit.dll” />
line is using (available here.) There’s also the community tasks project, which has a a bunch more (including the nunit task)

Hope that helps!

Thanx
Zak

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

Hi all!

Just a short one for now, I’ll update this with a few more usage samples in the near future.
You can download the bdd framework I used in most of the presentations. Its a mix of things inspired from  a couple different sources (nSpec, jpboodhoo, dan north and couple others) . It really is syntax sugar over whats already available - nUnit and rhino mocks.

In the download, I’ve included a test from the nUnit samples on MoneyBag using nUnit natively, and the same thing done using sugar. There’s also a sample on setting the expectations for the mocked objects.

From a Test first approach, BDD does provide a more fluent transition into thinking about the design of your objects, and how they collaborate with each other.

Hope this helps! (incase you missed it : you can download it from here )
Zak

Today I attended the windows 7 launch held by Skanco and Microsoft UK . It was great to see so many turned out to what was really a well presented and well managed event. It was held at the Palace cinema - which I think was a great choice.

Windows 7 seems to bring a few exciting bits with it when used as a stand alone OS and even more when knitted into the Win 2008 (and I presume next versions) “eco-system”.  During the demo we were shown a couple intresting things focusing on an enhanced user experience. It would have been interesting to see the federated networking in action though.

I think the Decks (thats what slides are now called) are available from Skanco and I’m sure they would (Skanco) be happy to answer any further questions.

Like I said a well presented and well run event, so a big thank you to Andrew (from Microsoft) and everyone at Skanco . Hopefully this will be a start to many more events on the Isle of Man

Thanks

Zak

Hey !!

The last in the soliD series. Dependency Inversion Principle - DIP, will be held on the 18th November 2009 -  25th November 2009 . Due to popular demand it was decided to postpone this as many could not make it. It should be at the same place (Dimension data-Isle of man) and for around the same time - start at 6:30pm. This will also be a good time to discuss the plans for the new year and finalize the curry night, so if you can make - great!!

So, back to DIP.

 High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

 Zak