Certified ScrumMaster notes

If you ever see anybody on the street giving a strange handshake and barking like a dog you have witnessed two ScrumMasters saying hello to each other. That was the last thing I learned last week at our ScrumMaster Certification Course held by Boris Gloger, the founder of Sprint-iT.

I won't go into detail about the course but I want to share with you my notes. They may not mean anything at all to you but I think they will mean the world to me in the next few months when I end up in situations where mindsets have to be changed, priorities have to be explained and roles and responsibilities are to be established.

I at first wanted to write them all down but I will try a new approach: The photography. I have seen many people use photos of slides and flipovers with crude drawings and always thought that whatever was on the slide now got put away in an image and wasn't properly "refactored" into useful notes. However, I ended up asking myself how useful my own notes are to me and to tell the truth I rarely (if ever) go back to notes I have made earlier. I must be doing something wrong otherwise I think I would be using them more often. So now I will try a new approach to see if pictures of Post-its saved on my harddrive will be of more value to me than notes properly entered in a Word document.

Here they are - the combined results and "Heureka"'s of two days of Scrum training. Read them all if you like and please do comment on any of them if they puzzle you or simply looks interesting to you.

Regards Kristian

 

P.S. - If the quality of the images are too low on the Web due to Blogspot fiddling with the size / quality of uploaded images you can download a zipped package of all the notes here. The image quality is not very high to begin with - this is because I had to take them with my mobile camera (the new HTC S730... Windows Mobile 6 with WiFi, GPS functionality, Qwerty keyboard and a default ringtone which scared the pants of several fellow customers at the local hardware store the first time somebody gave me a call)

P.P.S. - I noticed that one or two of them has Danish writings on them so if you bump into notes where you mumble "What the hey ???" then you should do a spellcheck to ensure that you are trying to decipher English notes instead of Danish  ;o)

Hello Rhino World

I have discovered something tonight - the art of testing through mocking. Yes, I admit it: I've never actually given much thought to the fact that mocking could be remotely interesting due to the fact that a mock is simply just a replacement for something you intend to test, i.e. a database access layer or external devices connected to your computer. I do not like to think of myself as being religious but nevertheless I have never given mocking a try because it just didn't feel right (!). So much for trying to see things from the other side - until now, because:

We have had quite a few exhausting weeks at work. Our source control is coming up to speed and a CI build enviroment is slowly emerging. It just builds everything but we are working disconnected from eachother and nobody can screw up the build for days without getting instant notice. I like it sooo much... We have hired one of my former collegues, who is now an independent consultant, to tell us about Agile development and TDD. Last Wednesday we talked a bit about mocking and I peeped a little about the paradox of testing a simulated version of the real world. However I decided that I would give a mocking framework a try one of these days and I tried it out tonight, so I created a simple scenario:

I want to create a Person object and store it in a database. The person should expose to me whether or not he has been saved or not. Separation of Concerns, I know, I know... I'm just mocking a scenario here... (applause sign on). And - tada - I want to test on both a real object and a mocked one and be able to retrieve a positive response whenever I ask Mr. Per Son: Have you been saved?

I downloaded Rhino Mocks because I had it recommended and it seems to be some sort of de facto standard these days - mainly because it is strongly typed which doesn't seem to be the case with other .NET mocking frameworks. I created the following unittests to mock my reallife Person object:

[Test]
public void CreateDomainObject()
{
Person p = new Person();
Assert.IsNotNull(p, "Person is null");
}

[Test]
public void RealPerson_NotPersisted()
{
Person p = new Person();
Assert.IsFalse(p.IsPersisted());
}

[Test]
public void RealPerson_Persisted()
{
Person p = new Person();
p.Save();
Assert.IsTrue(p.IsPersisted());
}

I then created a Person object to simulate this behaviour:

public class Person
{
private bool persisted;
public Person()
{
persisted = false;
}

public void Save()
{
persisted = true;
}

public bool IsPersisted
{
get { return persisted; }
}
}


...and now things get interesting. A mock of the Person is introduced in the following test:

[Test]
public void Mock_Persisted_Property()
{
IPerson persistedPerson = GetMockedPerson();
Assert.IsTrue(persistedPerson.Persisted);
}

private IPerson GetMockedPerson()
{
MockRepository mocks = new MockRepository();
IPerson person = (IPerson)mocks.CreateMock(typeof(IPerson));
Expect.Call(person.Persisted).Return(true);
mocks.ReplayAll();
return person;
}


The MockRepository makes it possible to take an instance of an IPerson object - that is, an interface describing the methods and properties on the object you intend to test. The domain object does not actually have to inherit the interface so if you do not want to have your domain model "interfaced" for various reasons, you do not have to. The IPerson I created is simply:

public interface IPerson
{
bool Persisted { get; }
}

I do not want to do anything with Save() so I leave it out of the interface. Maybe it is not best practise - I'm a newbie on this so you are obliged to guide me in the right direction if this has proven to be an anti-pattern.

In the Expect thingy I decide that a call to the Persisted property on my Person object should return true. The mocks.ReplayAll() stops recording expectations on my Person object and now I am ready to validate my expectations in my tests.

This makes it possible for me to run the Mock_Persisted_Property() test succesfully - and retrieve a positive value when asking if the Person has ever been saved even if the Save method has not been called. This is truly great because I have had numerous encounters with problems regarding third-party vendors and external hardware and processes which has not been testable for me until now either because testing them would result in extremely slow integration tests or that the tests themselves and the chance of a succesful test suite run would be extremely tightly coupled to a certain state of the hardware being tested (i.e. the hardware device should always be on and responding to requests).

I like this a lot. I have only scratched the documentation but I will definately go deeper into this during the next weeks and months. I have seen the light.- or at least seen the possibilities instead of only focusing on the limitations of mocking ;o)

Regards Kristian

P.S: - The entire source (Visual Studio 2008 solution) can be downloaded from this location

It has been quiet for a while

I just want you to know that I'm not dead or anything - just haven't had the time to gather my thoughts on the things we're working on right now. I'm about to become a Certified ScrumMaster late this month - having worked with Scrum for almost a year I think it is about time to get the theory in place. And I have made sure that every person in a Product Owner role at my new job have been submitted to the Product Owner course. And I have been a fireman all last week or so... Continuous Integration to the rescue in a not so distant future...

Hang on out there - I will share something with you guys when I have something ready for you guys.

Regards Kristian