Luncht v.3 - Session One - Chadrick's Take

I want to start by thanking Brian for trying TDD & PPP. I knew he had (maybe "has") a tendancy to shy away from pairing and I appreciate his openness to try it.

I also want to thank Dan Tape for throwing out the suggestion that we try Google Hangout for our dev sessions. As far as I'm concerned it's as good, and perhaps better than real life. Now we can base our showering habits wholly on our wives desires to be around us. if you have not tried Hangouts, do it and save some soap.

I had pre-written a feature called 'Registration' with a few bullets of acceptance tests to start with. I was basically following our precompiler format. Then because we are both familiar and fans of Pivotal Tracker I converted that item to a story with tasks for each of the acceptance tests.

Registration

As a user I need to be able to register for a new account so that I can use the system.

• Required Property FirstName
  User needs to have a FirstName property and it is required.
• Required Property LastName
  User needs to have a LastName property and it is required.
• Required Field Email
  User needs to have a Email property and it is required.
• Required Field Password
  Password field is encrypted once set.
• Password Field Needs to be Encrypted
  User needs to have a FirstName property and it is required.
• Default Chat Notifications
  During registration users are will be signed up to receive chat notifications.
• Default Deal Notifications
  During registration users are will be signed up to receive deal notifications

When we opened Visual Studio we started with a class library project and loaded NUnit and Moq with Nuget. We had one test at first with all the fields in it, but later refactored it so that each prop had its own test.

[TestFixture(Description = "As a user I need to be able to register for a new account so that I can use the system.")]
public class Registration
{
    [Test(Description = "User needs to have a FirstName property and it is required.")]
    public void RequiredPropertyFirstName()
    {
        // Arrange & Act
        const string firstName = "blah1";
        var user = new User( );
        user.FirstName = firstName;

        // Assert
        Assert.AreEqual(firstName, user.FirstName);
    }

    [Test(Description = "User needs to have a LastName property and it is required.")]
    public void RequiredPropertyLastName()
    {
        // Arrange & Act
        const string lastName = "blah2";
        var user = new User( );
        user.LastName = lastName;

        // Assert
        Assert.AreEqual(lastName, user.LastName);
    }
}

As you can see I've started putting the text inside of Description of the Test. I have an idea for a code generator that would build these tests out with an [Ignore] attribute on them. I might write about this in a future post. But as you can see we build our tests based on the required acceptance tests. Understand properties are not the sexiest of tests to write and perhaps a bit overkill, but it's TDD and we are 100% sure when done means done.

For most of this session we just did domain object tests. They were very basic and that allowed us to practice the Red >> Green >> Refactor Ping Pong Pairing workflow. For those of you who don't know what that is I'll give a quick run-through.

1. I start by writing a failing test. We decided our code had to compile so we had to create what was necessary for that to happen. I pushed the code to BitBucket for Brian.
2. He implemented the code to make the test pass and then checked it into HG and pushed it back to BitBucket.
3. We talked through things if necessary and refactored it accordingly.
4. Now it was his turn to write the failing test, so we jumped down to the next bullet.
5. I implement...
6. He refactors...
7. ...repeat

I was happy how it went. I'll let Brian give his own take on it.