Certified Scrum Professional

Last week the scrum Alliance CSP certification got approved!

The difference between a Mock and a Stub

Many people have a lot of problems to understand the difference between a Mock and a Stub. Marting Fowler states that a Mock is about behaviour verification and a Stub is about state verification
From: http://martinfowler.com/articles/mocksArentStubs.html

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive. 

I am going to try to explain you in one simple example the difference...
The classes involved:
FileProcessor: The actual business logic, that we are trying to test, the Subject Under Test
File: some file we are processing
FileValidator: Performs some logic on the file to see if it contains errors
FileMover: Moves the file to a specific location depending on the results returned by the FileValidator

public class FileProcessor{
        private readonly IFileMover _FileMover;
        private readonly IFileValidator _FileValidator;

        //Constructor
        public FileProcessor(IFileMover fileMover, IFileValidator fileValidator){
                   IFileMover _FileMover = fileMover;
                   IFileValidator _FileValidator = fileValidator;
        }

        public void Process(File file){
             ValidationResults result = _FileValidator.Validate(file);

             if(result.IsValid){
                  _FileMover.Succes(file)
             }else{
                  _FileMover.Error(file)
              }
        }
}

public interface IFileMover{
       void Success(File file);
       void Error(File file);
}

public class ValidationResults{
            public virtual bool IsValid{
                 get;
            }
}

public interface IFileValidor{
       ValidationResults Validate(File file);
}

We need to create a dummy called DummyValidationResults

public class DummyValidationResults: ValidationResults{
         public virtual bool IsValid{
                get{ return false;}
         }
}

Now we create a Mock MockFileMover

public class MockFileMover: IFileMover{

    public void Success(File file){
           this.SucessCalled++;
     }

    public void Error(File file){
         this.ErrorCalled++;
    }

    public int SuccesCalled{get; private set;}
    public int ErrorCalled{get; private set;}
}

We create a Stub named StubFileValidator

public class StubFileValidator: IFileValidator{
     public ValidationResults Validate(File file){
        return new DummyValidationResult();
    }
}


now when we would like the test the Fileprocessor we can write:
    File aFile = new FakeFile();
    MockFileMover fileMover =  new MockFileMover()
    FileProcessor processor = new FileProcessor(new MockFileMover(), new StubFileValidator());
    processor.process(aFile);

    Assert.AreEqual(1,fileMover.ErrorWasCalled);
    Assert.AreEqual(0,fileMover.SuccessWasCalled);

So what is the difference?
The stub returns a predetermined answer what needs to happen and the path through the code dictates it will always be called. As you can see the methods of the mock are enclosed in decision logic in this case an if statement (this can as wel be a try catch switch or whatever), then we verify if the correct method on the mock has been called... so the mock is responsible for failing or succeeding the test...

Executing all SQL files in a folder

SET dbName=RemmicomMeetingDb
SET sqlCmdCommand=sqlcmd -S . -E -i

%sqlCmdCommand% "DropAndCreateDb.sql"

FOR /F %%i IN ('dir /b /on *.sql') DO %sqlCmdCommand% %%i -d %dbName%

Incremental Software Delivery

What i see occur quite often is that User Stories are to big, resulting in work that is not done at the end of the sprint.

Lets take a look at the story below:

As an office manager I would like to be able to lookup contacts quickly so that I can quickly find someone's contact details.

Acceptance criteria

• Given an Office Manager enters "como" When I press the search button Then he/she should see the contact details of everyone who's full name contains "como"

• Given an Office Manager enters"ce" When I press the search button Then he/she should see the contact details off everyone's title containing "ce"
• ...

Now if we think about this for a second, we could start to break down the tasks as follows:

• Create the database tables
• Create the data access layer
• Create the DTO's
• Create the UI
• Create the service layer

If we stop and think about this a second it does not really make sense in a incremental delivery mindset. If you reflect on this from a Form Follows Function Perspective, that the shape of an object should be based upon its purpose. This is a faulty breakup of the feature we are trying to build, since we are going to make the purpose - storing the data in a database and then transfer it to a screen - take precedence over the function, searching contact details.
It makes more sense tobreak up the screen in functional components as shown below:

Then we could break the feature up as follows:

• Display Search Results
• Enter Search Criteria
• Display status message "x out of Y contacts"

This will require developers to shift there mind from "Horizontal thinking" - thinking in terms of technical layers, to vertical thinking - what I often refer to as "Slicing the Cake". This enables you to incremental delivery of features and get earlier feedback.
The most important thing is the green grid displaying the search results. From a technical perspective this seems a bit weird, since we autmatically think that its not usable once we have hundreds of contacts. But this mindset is wrong, it is workable, whether its practical that is another thing.
If we would take this approach we could deliver the following screen to the Product Owner:

If he can get his hands on this he can allready take a look and maybe he could allready experience this bit of functionality and conclude he would like to add some fields to the grid like email and phone, that he did not think of immediately.
So an extra task is added to the story "Add email and phone fields to the grid"
In the meanwhile wile the product owner is allready playing around with the screen we can allready add the yellow part to the screen:

This will enable very short continuous feedback loops, moreover working like this will help you deliver functionality sprint after sprint.
This is what the end result could look like

As you see apparently there was no more time for the status message at the bottom of the screen and this task has been removed from the story another change from the initial version is also the "Search" button.
Find here an overview of what was implemented and what was removed:
As an office manager I would like to lookup contacts quickly so that I can quickly find someone's contact details.

1. Display search results: Done

1. Enter Search Criteria: Done

1. Display status message "x out y contacts": removed

1. Add phone and email fields to the grid: Done

1. Filter results grid when typing text: Done

1. Remove search button: Done

There is one caveat with this approach, business user tend to like alot to add stuff, but they really dislike removing stuff… But this is where the timebox principle kicks in, if for instance there would be no more time left than the 2 last tasks (tasks 5 and 6) than the Product Owner might still choose to accept the story as done and the Functionality could potentially be shipped.

Scrum.org PSM II Certification

I reached a major milestone and obtained my Professional Scrum Master Certification II last week. A put alot of effort in it and it paid of.

Something on Continuous Integration

In the past I have been experiencing some weird practices concerning CI. In the following article I will outline some do's and don'ts when implementing continuous integration.

First and foremost it is ok to break a build that is why the thing is there you know. Comparing the number of broken builds against the ones that don't break is not a good measure of quality instead measure the time to fix the build.

Do Integrate static code analysis in your build like FxCop, Ndepend and Simian. Giving you early feedback on your code quality. If the tools give you warnings solve them as well. If you keep up on regular basis this will keep your code base clean.

Do Integrate your Unit tests to run every build. Again providing early feedback on integration issues.

Do provide visual feedback (Andon) that give people an immediate feedback when a build fails.

Don't force developers to do a get latest, run all their unit tests and then check in. This is a waste of time. But when a build fails fix it!

Don't seek who broke the build. Something that is very common is that people are very eager to investigate who broke the build and pointing fingers. Instead look what broke the build try to fix it, this will enhance collective code ownership.

Don't check in, close your laptop and sprint out of the office. This practice kills team morale.

Determine Iteration Length

Something I come across quite often is that teams don't consciously determine the iteration length of their sprints. They usually take 2 weeks as some default length. This is not really the way to go… Lets see what criteria we can put forward to fine tune the iteration length.
Here are the 3 major factors to consider:

• Project Duration
• End-User commitment (how available are they to provide feedback and input)
• Maturity of the team

The shorter the project the shorter the sprints enabling to have more feedback cycles, minimizing the risk building the wrong thing. This however will require a significant amount of commitment of the stakeholders (weekly review meetings, availability to clarify and develop the product backlog with the Product Owner,...). Short sprints also have one big advantage they are more prone to fail… The reason why I see this as an advantage is that problems will surface more quickly, enabling your team to address them and thus further minimizing risk.
The second factor is also quite important: are there end-users available to provide feedback and are they easily accessible? One thing to keep in mind is that people are not used to the fact they will have to be available for a project throughout its duration. In the past they participate in workshops in the beginning of a project and in acceptance testing testing near the end (oh sweet memories :))
Finally you should consider how mature your team is. This means how experienced are they with agile practices such as Test Driven Development, Continuous integration, Test Automation, Collective Code Ownership (instead of finding out who broke the build, investigate and fix what broke the build), being cross technical (no specialist like the database guy, the UI guy, etc.). This however does not mean there is no room for specialists and that everybody has to be a generalist but everyone chips in where needed. A big obstacle are teams that divide work parallel with the layers instead of what i call "slicing the cake", this means implementing a feature from front to back, this will enable them to incremently deliver software.

For more information see: Agile Estimation and Planning from Mike Cohn

EF CTP5 And Unit Testing

Using Entity Framework Code First CTP5 its quite easy to write and unit test your repositories. However test should still be written against the mappings of the actual database. It would be best to split the tests that write to the database from the tests that read into a different class

Just Create a class that inherits from DropCreateDatabaseAlways<T> override the seed method to create insert the values you want.

   1: public class DBContextInitializer : DropCreateDatabaseAlways<EntityContext>

   2: {

   3:     protected override void Seed(EntityContext context)

   4:     {

   5:         ProductDummies.GetAllProducts().ForEach(p => context.Set<Product>().Add(p));

   6:         context.Commit();

   7:     }

   8: }

And then put in your Unit Test Assembly the following method:

   1: [ClassInitialize]

   2: public static void ClassInitialize(TestContext context) {

   3:     DbDatabase.SetInitializer(new DBContextInitializer());

   4: }

If you then use an in memory database it will be fast. The best way to always start from a known state (and to avoid mstest concurrency problems is to put the following code in Your TestInitialize method:

   1: [TestInitialize]

   2: public void TestInitialize()

   3: {

   4:     string key = Guid.NewGuid().ToString();

   5:     TestContext.Properties.Add(DB_NAME_KEY, key);

   6:     repository = new Repository<Product>(key);

   7: }

To delete put the following snippet in your TestCleanUp

   1: [TestCleanup]

   2: public void TestCleanUp()

   3: {

   4:     repository.Dispose();

   5:     DbDatabase.Delete(TestContext.Properties[DB_NAME_KEY].ToString);

   6: }

Unit Testing ROI

In my experience everybody knows for sure unit testing is a good thing. But then again it puzzles me why nobody is actually doing it... I think one of the biggest misconceptions is that everyone thinks that unit testing pays back over time or in the long run. This is not true! There is a more immediate payback on your investment that pays off from the very first line of code! The returns on Unit Testing grow exponentially over time...

All projects go relatively smooth the first few months until they reach a certain point where the skeletons start falling out of the closet... Regression bugs start to appear at an alarming rate, it takes longer to detect errors, more time is spent in the debugger than actually writing code, it gets harder to add new functionality,etc,...

Unit testing will:

• Reduce the time spent in the debugger
• Reduce time to test your code as a developer
• Enables you to refactor

Reduce the time spent in the debugger

if you consistently write (good) unit tests you will be focusing on smaller portions of your code and thus preventing you to have to step through your whole application. When running all your unit tests you will automatically see when you break existing functionality, like this you will hunt down the likely cause a lot quicker (probably it was that last bit of code you changed).

Reduce time to test your code as a developer

When you unit test your code those little forms with one "test" button will be of the past. An other thing which will save you tremendous amounts of time is that it is no longer needed to step through a series of screens before you actually get to the functionality you want to test.

Enabling refactoring

If you have unit tests you can refactor those methods and classes that grow an keep growing... Everybody knows these little black holes in any application that are a pain to modify and every team member is reluctant to make modifications out of fear to break something else.

NDepend Enables you to quickly identify where problems will start arising. Find below some useful queries.

Types that are to big and need to be slimmed down

WARN IF Count > 0 IN SELECT TYPES WHERE
   NbLinesOfCode > 500 OR
   NbILInstructions > 3000
   ORDER BY NbLinesOfCode DESC

for more information: http://www.ndepend.com/Metrics.aspx#NbLinesOfCode

Methods that are to big or to complex

WARN IF Count > 0 IN SELECT METHODS WHERE
  ILCyclomaticComplexity > 40 AND
  ILNestingDepth > 4

OR NbLinesOfCode > 50 //Can even be smaller
  ORDER BY ILCyclomaticComplexity DESC

for more information: http://www.ndepend.com/Metrics.aspx#ILCC

C# 4.0 Code Contracts:

I was trying out the code contracts in C# 4.0 and came across something quite surprising every time I ran my unit tests I got an annoying message box popping up “Assert Failure”, Description must use the rewriter when using Contract.Requires<TException>.

After some googling around I found that in Project Properties you need to find the code contracts tab and set “Perform Runtime Contract Checking” to full.

I opened my project properties I realized I did not have the Code Contracts tab… So in order to enable this tab you will need to install Code Contracts from DevLabs (here: http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx).

Rebuild and he complained about the Assembly Mode Setting not being appropiate. After Changing it I could run my tests without having to click every time a testmethod came in the method that had the contract.

Problem solved!

Interface Contracts

One problem I came across is that when trying Interface contracts I had an assembly that ended in Contracts and apparently it does not work (Code Contracts will compile its contracts in a assembly named <assembly name>.Contracts.dll. I renamed the assembly to IContracts and everything worked as expected