fuzzelogic Solutions

Hi All!

I’ve uploaded the code used in the demo on the open closed priciple (part of the SOLID presentations) presented to the Isle of Man software developers group on the 19th of August 2009.

As a reminder….

1. All objects with names ending in Specs.cs are the “test” cases
2. The folder named “Attempt” is the first try at how we would have looked at solving this problem.(Breaks the OCP)
3. The folder “LosTechies” is the solution presented by LosTechies ( a possible solution -that I felt, although addresses the OCP, broke the SRP)
4. The folder “Fuzzelogic.Refactored” together with the folder “Infrastructure” contains the solution I presented making use of the specification pattern. It was easier to extend the appliaction when new requirements came about, and it provided us with a reusable “pattern” in extending the matching/filtering solution to other parts of  the application
5. The Bdd project is used to simplify the “test”ing of and makes for a more readable approach.

The code is available from here

All comments / questions are welcome.

Hope this helps

Zak

Hi!
Ok, following on from the last post, lets examine whats going on here. We have one main “outer” class called Login_Specification. Now my convention (based on work from jp and mspec) is to add an _Specification to the class name. To me, this provides a central location for all the scenarios for a login specification.

Next we have the “when_the_user_logs_in” class. This is the actual story. So in this case its the story that specifys the behaviour of “the user logging in”. This inherits from Story_For<> which is a generic base class that provides some syntax sugar, bringing bdd and the AAA style closer (more on this class later).

Next we have the “if_the_credentials_supplied_are_correct” class this inherits the “story” class above. This is the actual scenario. In the traditional unit testing world this would be your TestClass. This is where the “should” will created. So as an example, if the story + 1st scenario was …

“If the credentials supplied are correct when the user logs in, it should show the home page.”

This gives us executable code that

• matches our user story.
• can be run many times over to verify we are still “meeting the spec”
• can be automated

Hope this help!

Thanx

For everyone doing TDD (test first … test driven design) bdd is not going to sound like a lot of new stuff. BDD, at its core represents a change in thinking. It drives us down the path of writing out “specifications” so that its readable to everyone involoved in the software project. It steers developers into thinking about the behaviour in a given context, and what the “user experience” is going to be like.

It brings programmers close to the business…. that’s important enough to say it again. it brings programmers close to the business.

Additionally, BDD trys to get the words changed so that we stop communicating in terms of testing. We start talking about the behaviour of a system. Its worth mentioning, there’s a couple flavours in the BDD world. The Dan North “Given , When , Then” and then there’s Scott Bellware’s “Context specification” and of course mine (pretty much context specification based on sceanrios - each scenario is an If).

Using an example of a Login specification, let check each one.

Dans style : Given incorrect credentials when the user logs in then the user should be shown a failed to login message.

Scotts’s style: When the user logs in in [in the context of having incorrect details] then the user should be shown a failed login message

Mine: If the login credentials are incorrect when the user logs in, then the user should be shown a failed login message.

How this actually looks in code depends on the underlying framework used. For me, I’ve written up my own basic one, which relys on a few simple classes (I’ll post them at a later date)

// This is quick look at the layout of the test.
// The implemenation is left out for simplicity

BDD : Behaviour-Driven Development, is a software design technique that focuses on the behaviour of the application. What should the software do?

Its a shift in thinking from TDD, in which we refocus on the specification and not get caught up in verification.  In  later posts we’ll discover the crux of bdd, but for now there’s a bunch of tools we need.
Hard tools:
•Unit test framework
•Mocking framework
•Refactoring tool
Soft tools:
•Understand OO
•Design principals
•Design patterns
•Refactoring : learn to identify the smells

So where do you start. Well to be honest, the first place to start is on soft tools. 

Over the next few posts we’ll do just that, we’ll cover the basics of OO, SOLID design  principles, patterns and refactoring, and since I’m a c# guy all examples will be in c#.

So till next time.

Hope this helps!

Zak