Before we jump into SpecFlow, let us get some of the terms and nomenclatures around this tool straightened. We will be using some of these terms over and over again in the course of this post. Two such very important terms are Feature and Scenario.

Feature – a logical unit of functionality which has a business value. For example, the ability to add a customer to the system is a feature, or the ability to send an email with the product catalog to a customer can also thought to be another feature. Creation of the “CUSTOMER_MASTER” table in the database in not a feature.

Scenarios – different conditions around a feature and the system’s expected behavior against these conditions. For example, if the customer is successfully added to the system, the user should be taken to customer-list page. If the customer is not successfully added then the user should remain in the same page and the reason of failure must be displayed.

In order to understand the idea of Feature and Scenario better, let us use an overly simplified feature for an example. Let us assume that we want to build a feature called “Customer Addition”. As the name suggests, we intend to develop a Feature which will allow the user to add a customer to the system. Let’s say we come up with two scenarios – First, when the user is successfully added to the system, and second when the user is not successfully added to the system.

SpecFlow uses  english-like language called Gherkin to write these Features and Scenarios. Gherkin is a DSL(Domain Specific Language) and hence can be understood by the Business folks and the SMEs quite easily. Gherkin uses .feature file to specify a Feature. The Feature keyword marks the beginning of a feature. For more details on the syntax of Feature see this link. This descriptive text in nature and is used to describe what the feature is supposed to do. It need not necessarily follow a particular convention or pattern. SpecFlow recommends using the following template though.

A Feature typically consists of one or more Scenarios. The scenarios must follow the Given-When-Then syntax,

Okay! Back to our “Customer Addition” feature. SpecFlow installs few templates in the Visual Studio. One such template is called SpecFlow Feature File and has the .feature extension. Let us create our feature using the SpecFlow Feature File and name it CustomerAddition.feature. In light of the conventions discussed earlier in the post, the feature should look something like this,

What is actually happening here is that every time the Feature file is saved, SpecFlow parses it and generates a code-behind file for it. Under the hood, all this generated piece of code essentially does is call few methods (tests) for these Given, When and Then statements. If we go ahead and try to run our Feature file (using MSTest or NUnit) at this point, we will see that SpecFlow is complaining that it does not find a matching step definition for the Given, When or Then statements.

Let’s go ahead and add something called the SpecFlow Step Definition file from the Visual Studio. A Step Definition File tells the runtime which method (step) should be executed for a Given or When or the Then statement. This wiring up is done by the [Binding] attribute that decorates the StepDefinition class. If our Step Definition Class were called the CustomerAdditionStep, then using the generated code in the error message we can create a class which would look like the following,

We can write tests and assertions using these methods and automate a business scenario using these step definitions.

This is a very simple demonstration of how a tool (SpecFlow in this example) can be used to provide a common platform for both business and the development folks to be able to collaborate, develop a shared understanding of the system and then be able to automate that shared understanding. In other words, SpecFlow allows the devs and the BAs to collaborate and define executable behaviors for the system (in terms of scenario) and then let these set of behaviors drive the development of rest of the system.

Another ailing thing about TDD is the name itself. ‘Test’ driven development is hardly about testing. It has never been about doing the tester’s job. Many people would say TDD is and has always been about good design. I do not completely agree with that either. Good design is a very good by-product of TDD, but that’s not the primary purpose of TDD. The very name and the nomenclature around it, words like Test, Assertion etc, influences the brain (Sapir–Whorf hypothesis) compels it to think that TDD has got something to do with testing.

TDD also requires a fundamental shift in focus as a developer. For decades we developers have been thinking about those grand software designs up-front, creating the databases, the data-access classes, the business facades, re-usable components and what not before addressing the actual business needs in small bits. TDD done right demands for a drastic change in this mindset. It requires the developer to think about the business needs first. Pick a very tiny slice from it which still has a business value and write only as much code that is required to implement this piece of business value. Really, this might not be the most intuitive thing to do for most of the developers. Moreover, this ‘no up-front design’ idea (though I do not completely agree with it) does not work in the best interest of someone like me who sell themselves as ‘Architects’. Pun intended!

No wonder so many teams struggle to get TDD right.

Due to some of these inherent problems with TDD and the huge gray area without sufficient guidelines on what and how much to test, people like Dan North came out with the idea of BDD a.k.a. Behavior Driven Development. The idea behind BDD is pretty simple. The idea is to provide a common tool and guideline to both the business and development folks. This tool/guideline would allow the business analysts and SME’s to write the business requirements (in a specified format) using english-like language. They would write the different business scenarios around the requirement. In other word, they would define the ‘Behavior’ of the system. The same tool would be able to generate or at least guide developers write the test-cases from these scenarios. The developers would implement these test-cases one by one and make all the tests go green. And TADA! In a perfect world, you have a business requirement translated into a working code.

With BDD the point really is to be able to write tests which are more relevant. Tests which matter. Tests which are derived right out of the business requirements and scenarios, coming right out of the horses mouth. BDD is about putting some more structure and discipline into the Test Driven practices you already claim to do.

With the passing every single year in the world of software development I find myself more and more convinced of the fact that every project and every team is unique. They have unique situations and requirements. One should accept and adopt tools and processes only to the extent that fits the personality and culture of the project team and caters to the needs of the project. Let me share a tale of a team that I worked with in recent times.

The team was maintaining a suit of unit-tests around the code. Though the code coverage was decent, the execution coverage was really poor. If you ran the test-suit, at any given point, many if not most tests would fail. Not a happy situation to be in, especially, if you are willing to leverage the benefits of units tests. One of the most important benefits of having a unit tests around your code is to provide you with the courage and the confidence to refactor your code fearlessly. You should be able to make a change in the code and run the tests to make sure everything is alright. And this is what the team was badly missing with it’s tests. Any “red” test that we came across would not clearly conclude that weather the test failed because of bad data or the functionality was actually broken. We dug into the each and every unit-test. To our relief we found almost all the failing tests were failing because bad test-data and not broken logic. Believe me or not this is the case with many teams claiming to maintain unit-tests.

We fixed the test-data, created dummies, mocks and stubs where required and made the test-suite hundred percent pass. We would setup data before running the tests and undo the changes to the database (or other states) after the tests ran. Hence, the test-suit always remained automated.

The next logical question then was how are we going to make sure that the tests we fixed this time around would not run into the same issue in the future. The answer was obvious – Continuous Integration (CI). With Microsoft’s Team Foundation Server (TFS), it was fairly easy to set up the build for Continuous Integration. Once we configured the CI, we realized that the builds were heavy and slow as many of these tests talked to the database. It was turning out to be an overkill for the return we were achieving. Again, we followed the “horses for courses” strategy. The pragmatic solution that we all agreed upon was that instead of queuing a build at every check-in, we should trigger the test-run only in the nightly builds. That way we were sure that code integrates at least once every day. Something we happily lived with.

The idea behind telling the story is that tools, process and best-practices are not meant to be followed like commandments. One should certainly look out for and be aware of what’s working for most teams out there, borrow the idea as and when necessary but should not impose them on the team. They should be adopted and accepted according to the teams comfort and adopted as per the teams need.

As you would have already understood that what we followed was not even close to be called TDD. We just maintained unit tests. But at the end of the day we delivered, and delivered well. Isn’t that all that matters? Isn’t it more important to do what works than what is right? After all, isn’t it true that there is no single key for every lock?

But user story card is just a part of the story. Let us try look at the whole story itself. Please allow me to tell you the story of user stories.

A user story describes desired functionality from the business perspective; it is the user’s story. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. I completely agree with Mike Cohn’s favourite Template for writing user story which are short and simple,

As a [user role]

I want [functionality]

So that [reason]

 A user story is comprised of:

1. Card – the written description of the story, serves as and identification, reminder, and also helps in planning.

2. Conversation – this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.

3. Confirmation – the acceptance test criteria that the user will utilize to confirm that the story is completed.

A very good guideline for writing good user stories is the INVEST model

Independent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.

Negotiable – A user story is negotiable. The “Card” of the story is just a short description of the story which do not include details. The details are worked out during the “Conversation” phase. A “Card” with too much detail on it actually limits conversation with the customer.

Valuable – Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.

Estimable – The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).

Small – A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.

Testable – A story needs to be testable for the “Confirmation” to take place. Remember, we do not develop what we cannot test. If you can’t test it then you will never know when you are done. An example of non-testable story: “software should be easy to use”.

So the moral of the story is this. User Stories being the cornerstones for Agile development, deserve their fair share of time, effort and most importantly prudence to be “invested” in them in order to lay a strong foundation for project.

Amid all the mumbo-jumbo around it, I find these IOC Containers very simple at their hearts. IOC Containers are essentially a tool for Dependency Injection. The idea behind is to invert the flow of program control in a manner that maximum amount loose coupling can be achieved. Hence the name IOC (Inversion Of Control) Container.

Sounds vague? Let us jump into some code in order to understand this. Allow me to use the example of my favorite ‘PizzaStore’ class.


Public class PizzaStore
{
   Public ChickenPizza Prepare()
   {
      ChickenPizza pizza = new ChickenPizza();
      pizza.Prepare();
   }
}


In the light of Dependency Inversion Principle (DIP) , this is not the right way of doing it. For every new Pizza class that is created in the system there needs to be a new PizzaStore class. This is because the PizzaStore class depends upon the Pizza class. A desirable design goal (according to DIP) here would be that the Pizza and the PizzaStore class should be decoupled in a manner that same PizzaStore class should be able to work with different types of Pizza. In other words, the dependency between Pizza and PizzaStore should be so inverted that PizzaStore should not directly depend on Pizza class. As a matter of fact, according to DIP, it should depend on an abstraction (IPizza interface in this case).


Public class PizzaStore
{
   Public ChickenPizza Prepare(IPizza  pizza)
   {
      pizza.Prepare();
   }
}


The client program must take pass the right dependency (instance of pizza) to the IPizza. This tecnique of injecting the dependency from outside is called Dependency Injection.

If we separate out the piece of code that assumes the responsibility of inverting the flow of control of the system in comparison to procedural programming using the technique of Dependency Injection, we would call this piece of code an IOC Container. 

An IOC container, at the very basic should be able to do two things
• Register a Dependency
• Resolve a Dependency

For the ease of understanding, let us start with the Resolve part. Take a look at the following code,


public class PizzaStore
{
   Public IPizza Prepare()
   {
      Return Container.Resolve<IPizza>();
   }
}


Here the Container determines and returns the right instance of the Pizza. Hence, whenever an instance of the type Pizza is required by the PizzaStore class, it will request the Container to resolve and return the right instance for the Pizza. This means that it is the responsibility of the Container to instantiate a class. This also means that the Container needs to have the information about what instance should it return for a given type. This is when the Register part comes into picture. The Register method tells the Container what object should be returned for a given type.


ChikenPizza chkPizza = new ChikenPizza();
Container.Register<IPizza>(chkPizza);


Or sometimes,


Container.Register<IPizza>(ChikenPizza);


Most of the existing IOC containers allow an ability to Register through configuration also. A typically full-blown IOC Container also provide with other sophistications like managing the scope and lifetime of the instance. For example, would you like your object to be instantiated on per call basis, or per thread basis or should your instance be a singleton instance.

In a nutshell, all that an IOC Container essentially does is know what instance to be retuned for a given type and then return that instance through an abstraction (generally interface) using dependency Injection.

HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
ABSTRACTION SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTION.

Let’s try to understand this with an example. As I write this post on a Sunday evening enjoying a Four-cheese pizza slice (yummy!), all I can think of for an example is pizzas. Let’s assume a class called PizzaStore, which has a specialty in Grilled Chicken pizzas. Hence it sells only this Grilled Chicken pizza. Let’s call this class as ChickenPizza.

public class PizzaStore
{
    public void CreatePizza()
    {
        ChickenPizza pizza = new ChickenPizza();
        pizza.Prepare();
    }
}


Here the PizzaStore class is said to be the higher-level class and ChickenPizza class is the lower-level class. Hence we have a high-level class depend upon the low- level class. But so far, this is perfectly fine and acceptable as there is just one type of pizza to prepare.

Time passes, and our little PizzaStore becomes more popular. The business grows and so the demands. Its time that they add some more veriety to the kind of pizzas they sell. The Pizza store introduces a new pizza – the famous Chicago Deep Dish pizza. Lets this be called the DeepDishPizza.

This will require the high-level PizzaStore class to change a little to accomodate this new low-level DeepDishPizza class.

public class PizzaStore
{
   public void CreatePizza(string pizzaType)
   {
      if (pizzaType == "DeepDishPizza")
      {
          DeepDishPizza pizza = new DeepDishPizza();
          pizza.Prepare();
      }
      else
      {
          ChickenPizza pizza = new ChickenPizza();
          pizza.Prepare();
      }
   }
}


This means every time a new Pizza type is introduced, the PizzaStore class will need to change. That is, the high-level class will need to change if a low level class changes. With increase in number of these pizza classes the coupling will keep on increasing. Plugging in a new type of pizza will not very easy, even for this overly simplified PizzaStore.

Let’s try analyze if DI can come to the rescue as far as our little PizzaStore is concerned.

In order to implement DI here, we will need to abstract out the commonalities of these pizza classes in an abstract class called Pizza class.

public abstract class Pizza
{
   public virtual void Prepare();
}


Let all the pizza classes inherit from this class and implement their own version of Prepare() method.

public class ChickenPizza: Pizza
{
   public override void Prepare()
   {
      ...
   }
}


public class DeepDishPizza: Pizza
{
   public override void Prepare()
   {
      ...
   }
}


And the PizzaStore class will work only with the abstraction of Pizza

Public class PizzaStore
{
   private Pizza _pizza;
   public PizzaStore(Pizza pizza)
   {
       _pizza = pizza;
   }
   public void CreatePizza()
   {
       _pizza.Prepare();
   }
}


This technique of passing (or injecting) the instance (Dependency) on to the depending class (PizzaStore) class is called Dependency Injection.

The technique is simple but very powerful to achieve the ultimate design goal – “Loose Coupling”.

Uncle Bob’s SOLID principles are a collection of five OO design principles. These are:

1. Single Responsibility Principle (SRP)
2. Open Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

DIP

THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.

OCP

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION.

LSP

FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.

ISP

CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE.

SRP

HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
ABSTRACTION SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTION.

Irrespective of whether you are on Uncle Bob’s side or Joel’s side, these principles to me are great pointers to a good software design. Of course, like any other engineering principles, these should not be treated as commandments. Rather the requirements of the project should dictate the degree of relevance of these principles in their case. That is where Coding becomes a Craft and not mere a discipline of science.

With that said, having the mind laden with these principles will definitely put ones thinking in the right direction. In the direction in which the fundamental requirement of all good software design can be achieved – “Loose Coupling”.

I always used to wonder that why should somebody like me who is more responsible for coding and designing part of the software development process be concerned about Testability? Why should I take the pain to coding for testability? What does it bring to the table for somebody like me?

Well! The answer is, “better design”.

In order to make a code more testable, the classes must have the ability to be tested in isolation. This means more mockable classes. It is easier to mock classes which are interface driven (Yes, we are talking about Design by contract here). Also, in order to make classes easily mockable, they must be as loosely coupled as possible. The dependencies must be abstracted out. Hence, good design practices like Dependency Inversion Principle becomes an obvious candidate for consideration.

To achieve high testability, i.e. degree of ease with which a piece of code can be tested, the classes must be smaller, focused and cohesive in nature. That is, they should focus on one or few related piece of functionality. Such classes are easier to maintain and tend to have neater Separation of Concerns. Such classes are closer to Single Responsibility Principle at their hearts.

The more testable the code is, the more coverage it tends to have. This is because of a simple reason that writing more and more tests for such code is easier. This allows the developers more cushion to refactor those pieces of code which has become obsolete and ugly over a period of time.

Hence, coding for Testability is all about writing more maintainable, flexible and robust code. Code which has a solid foundation and code which can withstand the only constant of software development life – change.

This set me out to dig deeper into this highly hyped term. And really, the crux of finding was that the so highly hyped SOA is nothing but just a natural growth of the craft of developing software. The craft has come up a long way from procedural to object-orientation to component-based and now to service-orientation. Of course, every stage has had its own compelling drivers to take it to the next one. Hence, SOA is no revolution, it is just an evolution. There are business (rather marketing, lol) aspects to SOA too. But let us limit our focus to SOA as software development approach.

So what is SOA? In order to qualify itself as an SOA, an architecture must adhere to the infamous Four Tenants of SOA. Which are:

Boundaries are explicit. Developers should define explicitly what methods/properties are going to expose to the client.

Services are autonomous. Services and the consumer application are independent. So in future if we need to modify or enhance the services feature then we can take the services offline and work with that. So this won’t affect the consumer application.

Share Schema/Contract not class implementation. We need to share only the schema to our clients. If should not share any implementation information in to our clients. For example, we should not ask them to give any connection string info in the attribute level, which will expose what database we are using for our service.

Compatibility based on policy. The services should define all the requirements in order to use the services. We should not have person – to – person communication about the services.

So next time when you profess to have implemented SOA, check against these tenants to make sure that you are not exaggerating.

Cheers.

Is anything wrong about having a class to do more than one thing? Well, the Single Responsibility Principle (SRP) says “Yes” there is.

Consider the following class:

This is the what the class does for you:

1. Saves the newly created employee object to the database,

2. gets the list of employees in the database,

3. calculates the Gross from the basic using the business rule,

4. Sends email Notifications to the employees.

Now if you were to give a meaningful, unambiguous and self-explanatory name to the class GiveMeName, what would you name it? Well, confusing … isn’t it?  The confusion is a very good indicator of the fact that we are doing something unfair to the class here. We are making the poor guy cater to too many responsibilities.  I bet the best name you can think (like me) would be Employee or EmployeeManager. This is where we lose the trick.

Try breaking the GiveMeName class into three small classes:

These classes are much more focused and their names are beautifully self-explanatory and suggestive of their purpose and meaning of existence. They tell you why were they born and why do they exist. Thus there would be one and only reason for any of these classes to change, for, there is one and only one responsibility these classes cater. This will ensure Orthogonal code and hence maintainability of your code. It will help your code to stay closer to universal principle of programming - Tight Cohesion and Loose Coupleing.

So next time when you create a class and find that it’s name doesn’t come obviously to you, and you have to satisfy yourself with some “Manager” kind of name with your class, think twice, think if you have taken a leaf out of the book of SRP.