C# Development and TDD

TDD with Objective-C and Calculator Kata (using JetBrains' AppCode)

2012-02-13T22:11:00.000-08:00

I've just created a 1 hour tutorial/screencast that demonstrates TDD in objective-C (iOS 5) via Roy Osherove's Calculator Kata. The screencast primarily uses JetBrains' new AppCode IDE for objective-C, but it also flips occasionally into XCode 4.2 to set up a storyboard with a simple UIViewController that connects to the TDD-created Calculator class.

The screencast demonstrates a variety of layouts and keyboard shortcuts for AppCode (and to a lesser extent, XCode) as well as covering a number of language features of objective-C.

Please have a look, and if you have any questions, send me a comment at my twitter account.

Screencast: Learning Objective-C via TDD and Calculator Kata

DDD Kata, Part 4 (Service Layer with Mocks)

2012-02-12T13:35:00.000-08:00

Pre-Requisite: DDD Kata Part 3

Kata Review
In part 2 of the kata, you built a simple service test to demonstrate the passing of the Item from the Inventory aggregate root to the Invoice aggregate root. In part 3 of the kata, you created IUnitOfWork interface to manage atomic transactions with commit and rollbacks.

Now we need to design the real service.

In this test we will "inject" repository interfaces into the service class constructor to do the work of persisting the state changes to our domain entities. The UnitOfWork we created in part 3 of the kata will assist us in this effort.

Completed kata example on github: DDD Kata Part 4 sample code (github)

NOTE If you haven't already download RhinoMocks, download it and add the DLLs to a 3rd Party Libs directory for reference.

1. Open the previous solution you created in kata 3.
2. Add a reference to RhinoMocks.DLL to the library "Kata.Services.Tests.Unit".
3. Use RhinoMocks to mock the following interfaces (use Resharper to generate the new ones).
NOTE Your mocking levels are stub, dynamic, and strict. The 3rd choice strictly enforces the test specfiications. Start with a strict implementation for now.

IInvoiceRepository
IInventoryRepository
IUnitOfWorkFactory
IUnitOfWork


private MockRepository _mockRepository;
private IInvoiceRepository _invoiceRepository;
private IInventoryRepository _inventoryRepository;
private IUnitOfWorkFactory _unitOfWorkFactory;
private IUnitOfWork _unitOfWork;

[SetUp]
public void SetUp()
{
    _mockRepository = new MockRepository();
    _invoiceRepository = _mockRepository.StrictMock();
    _inventoryRepository = _mockRepository.StrictMock();
    _unitOfWorkFactory = _mockRepository.StrictMock();
    _unitOfWork = _mockRepository.StrictMock();
}

4. Create a test.
5. Enter code comments, and basic Rhino Mocks method calls, to generate a test skeleton:


[Test]
public void CreateSimpleInvoiceMethod_ProductCodeAndSerialNumberInputs_GenratesSimpleInvoice()
{
    // declare constants

    // expectations
 
    _mockRepository.ReplayAll();.
    // call to new service method
    _mockRepository.VerifyAll();
}

Now populate the test skeleton as follows:
6. In declare constants, create constants for productCode and serialNumber
7. In declare constants, build an Inventory instance using method StockItemBy()
8. In declare constants, create an Invoice
9. RhinoMocks tests based on object equality, so make sure you have assigned Ids to all your objects.


// declare constants
const string productCode = "ABCD1234";
const string serialNumber = "BB2135315";
var inventory = new Inventory { Id = 1234 };
inventory.StockItemBy(productCode, serialNumber);
var invoice = new Invoice() { Id = 1234 };

10. In expectations, expect that IUnitOfWorkFactory creates IUnitOfWork.

NOTE If the Create() method exists on the implementation class (UnitOfWorkFactory) but not on the interface, use Resharper to generate it on the interface.

11. Expect that InventoryRepository.LoadInventoryByProduct(IUnitOfWork uow, string productCode) returns Inventory instance.
12. Add comment: // Call to Inventory.PullItemBy(productCode)
13. Add comment: // Call to Invoice.BillItem(item)

NOTE These must be comments only as they aren't on mock objects. Actual calls would reduce inventory to zero in no context and cause a null error below.

14. Expect that InvoiceRepository.Save(IUnitOfWork uow, Invoice invoice) saves invoice.
15. Expect that IUnitOfWork.Commit() is called

NOTE If the Commit() method exists on the implementation class (UnitOfWork) but not on the interface, use Resharper to generate it on the interface.

16. Expect that IUnitOfWork.Dispose() is called


// expectations
Expect.Call(_unitOfWorkFactory.Create()).Return(_unitOfWork);
Expect.Call(_inventoryRepository.LoadInventoryByProduct(_unitOfWork, productCode)).Return(inventory);
// Call to Inventory.PullItemBy(productCode)
// Call to Invoice.BillItem(item)
_invoiceRepository.Save(_unitOfWork, invoice);
_unitOfWork.Commit();
_unitOfWork.Dispose();

17. Between ReplayAll and VerifyAll, create InvoicingService instance with all mocked interfaces.


_mockRepository.ReplayAll();

var sut = new InvoicingService(_unitOfWorkFactory, _inventoryRepository, _invoiceRepository);
Invoice actualInvoice = sut.CreateSimpleInvoice(productCode, serialNumber);

_mockRepository.VerifyAll();

18. Now use Resharper to generate the method under test: InvoicingService.CreateSimpleInvoice(productCode,serialNumber).
19. Run the test and watch it fail.
20. Use the expectations set in the test to assemble the method.
21. Remember to wrap the call in IUnitOfWork using statement, and to commit at end of the block


public Invoice CreateSimpleInvoice(string productCode, string serialNumber)
{
    using(IUnitOfWork unitOfWork = _unitOfWorkFactory.Create())
    {
        Inventory inventory = _inventoryRepository.LoadInventoryByProduct(unitOfWork, productCode);
        Item item = inventory.PullItemBy(productCode);
        var invoice = new Invoice();
        invoice.BillItem(item);
        _invoiceRepository.Save(unitOfWork, invoice);
        unitOfWork.Commit();
        return invoice;
    }
}

22. Invoice will fail because its Id cannot be known, so MODIFY the expectation for InvoiceRepository.Save() by adding:
LastCall.IgnoreArguments();
23. All tests should now pass.

This completes DDD kata part 3.

The next kata will introduce Fluent NHibernate as an implementation framework against the domain entities and repository interfaces that you have created so far.

DDD Kata, Part 3 (build atomic transaction manager i.e. UnitOfWork)

2012-02-12T13:15:00.000-08:00

Pre-requisite: DDD Kata Part 2

Kata Focus
1) Work occurs in the Repository layer, which will be used to persist to and from a data store. The data store will be encapsulated behind interfaces.
2) A pre-requisite activity is to build a wrapper interface to encapsulate transaction commit/rollback, with commit and rollback occurring on Dispose().

Completed kata example on github: DDD Kata Part 3 sample code (github)

The Kata
Time goal: under 30 minutes

Repository layer
1. Create new class libraries:

Kata.Repository.Tests.Unit
Kata.Repository

2. Add a reference to the NUnit.Framework.dll in the new test library.

We will start by creating the interface to wrap transaction commits and rollbacks. For an initial, simple name, we'll use AtomicTransactionManager. In a few minutes we will refactor that to use the name of the corresponding design pattern.

Repository: AtomicTransactionManager
1. In the new Repository unit test library, create class AtomicTransactionManagerTests.cs
2. Verify that AtomicTransactionManager is instance of IAtomicTransactionManager.
3. Verify that the constructor of AtomicTransactionManager sets TransactionState property to “Is Begun”.

NOTE You should be using Resharper's "generate-by-usage" (alt-Enter) to generate these properties and methods of the sut. However, make sure that the declared type on the sut is interface, otherwise your generate-by-usage will create class-only properties and methods. It should be creating the properties and methods on the interface.

4. Verify that Commit() method sets TransactionState property to “CommitRequested”

The actual name for this design pattern is UnitOfWork. You can read about it here: Martin Fowler, PEAA: Unit of Work

5. Refactor the class and interface you have created so far to UnitOfWork and IUnitOfWork
6. Verify that IUnitOfWork is instance of IDisposable
7. Verify that the Dispose() method sets TransactionState property to “RolledBack”.
8. Verify that calling first the Commit() method, then the Dispose() method, sets TransactionState Property to “Committed”.

UnitOfWorkFactory
Use a factory class to encapsulate the generation of the IUnitOfWork.
9. Verify that UnitOfWorkFactory is instance of IUnitOfWorkFactory.
10. Verify that IUnitOfWorkFactory.Create() returns an IUnitOfWork instance.

Part 3 of the kata is complete.

In the next kata, we will build the service layer with repository interfaces and mock objects.

Continue with DDD Kata Part 4

DDD Kata, part 2 (Add second aggregate root to domain. Service method stage 1)

2011-11-22T18:27:00.000-08:00

Pre-requisite: DDD Kata part 1

Completed kata example on github: DDD Kata Part 2 sample code (github)

Kata Focus
1) A second aggregate root (Inventory).
2) Business methods in each aggregate root to transfer a Product's Item from Inventory to Invoice
3) Service method, stage 1: Non-persistent, no mocks; only to verify service method created, and that it passes Item across the aggregate roots.

NOTE The next kata (part 3) will introduce design of service orchestration through mocks, repository interfaces, and IUnitOfWork with IUnitOfWorkFactory.

The Kata
Time goal: under 30 minutes

Domain: Inventory

Note Steps 1 through 5 work through the same concepts (object identity, read-only collections, sets) as were explored in DDD kata part 1. You may wish to build to the end of step 5 only once, and then use this as a jumping off point for the newer material in kata 2.

1. M: New test classes for Inventory, Product and Item--start by verifying that they are instances of DomainEntityBase.
2. M: Verify that Inventory.Products is read-only collection (instance of IEnumerable<Product>).3. M: Verify that Inventory.AddProduct() increments Inventory.Products collection property.
4. M: Verify that Product.Items is read-only collection (instance of IEnumerable<Item>).
5. M: Verify that Product.AddItem() increments Product.Items collection property.

New concepts begin here.
Domain: DomainEntityBase
Changes to DomainEntityBase are necessary for proper collection add/remove behaviour on transient objects (with Id = 0).
1. M: Verify that TransientId is of type System.Guid.
2. M: Verify that TransientId has a non-empty value (i.e. not = Guid.Empty).
3. B: Verify that two instances of DomainEntityBase with 0 Id, but matching TransientId values are equal.

Domain: Inventory
4. M: Verify that Inventory.GetNewOrExistingProductBy(string productCode) returns product with matching code.

Hint The methods in tests 7 and 8 will both call to the method created in test 6.

5. M: Verify that Inventory.StockItemBy(string productCode, int serialNumber):

increments count of Inventory.Products.First().Items
sets Product.ProductCode and Item.SerialNumber

6. M: Verify that Inventory.PullItemBy(string productCode):

returns Item from Product.Items
decrements Product.Items (i.e. the Item has been removed)

Domain: Invoice
7. M: Refactor LineItem. Change its Product property to reference Item instead. Fix and update any broken tests.
8. B: Verify that Invoice.BillItem(Item item) increments Invoice.LineItems, and that the LineItem references the billed Item.

Service layer, Stage 1
Non-persistent, just verifying the football pass of Item from one aggregate root to another.

1. M: Create new class libraries:

Kata.Services.Tests.Unit
Kata.Services

2. B: Verify that the Item pulled from inventory by productCode is the same item billed to the Invoice.

Part 2 of the kata is complete.

Continue with DDD Kata Part 3

DDD Kata, part 1 (simple domain: Invoice and LineItem)

2011-10-30T11:32:00.000-07:00

Kata Focus
1) Object identity and equality by Id
2) Id maintained in base class (entity object)
3) Equality on properties (value object)
4) A single aggregate root
5) Associations controlled from aggregate root (read-only, unique sets)
6) Business logic verified from the aggregate root

The kata will focus 80% on ORM mechanics (such as ORM issues of identity and equality) and 20% business requirements; tests are therefore delineated as M (for Mechanics) or B (for Business requirement).

The Kata
Time goal: under 30 minutes

A. DomainEntityBase
1. M: Verify that two instances of DomainEntityBase are equal when they have the same ID value
2. M: Verify that two instances are NOT equal when they have different ID values
3. M: Verify that two instances are NOT equal when they have 0 ID values.

B. Invoice, Money, and LineItems association
1. M: Verify that Invoice is an instance of DomainEntityBase.
2. M: Verify that LineItem is an instance of DomainEntityBase.
3. M: Verify that Money's constructor accepts Amount (decimal) and Currency (string) parameters whose values match equivalent properties.
4. M: Verify that Money.Amount and Money.Currency properties are read-only
5. M: Verify that two Moneys are equal when they have the same Amount and Currency.
6. M: Verify that Invoice has a read-only collection of LineItems.
7. M: Verify that adding a LineItem to Invoice increases its count of LineItems from 0 to 1
8. M: Verify that adding the SAME LineItem (by identifier) does not increment the set of LineItems.
9. M: Verify that the bi-directional reference (LineItem.Invoice) equals the owning Invoice.
10. B: Given an existing LineItem, when I try to add a LineItem without a ProductCode,
then I am informed that I must provide a ProductCode.

Bonus (outside the 30 minute kata window)
1. B: Given an existing LineItem with Price (type Money) of Currency CDN, when I try to add a LineItem with a USD Price, then I am informed that all LineItems must share the same Currency.
2. B: Given a set of LineItems, when I check the SubTotal for the Invoice, then the SubTotal matches Sum of the Quantity of LineItems times the Price.
3. B: Given an existing LineItem, when I try to add another LineItem with the same ProductCode,
then the original LineItem for that ProductCode has its Quantity incremented by the quantity of the added item.
4. B.Given an Invoice with LineItems, when the Currency of LineItems is USD and the SubTotal > 100M, then the Discount amount equals 5% of the SubTotal.

Continue with DDD Kata part 2

*****

Test Examples
DomainEntityBase, test 1:


[Test]
public void TwoInstance_SameIdInput_AreEqual()
{
    const int id = 1325123;
    var sut1 = new DomainEntityBase { Id = id };
    var sut2 = new DomainEntityBase { Id = id };

    Assert.AreEqual(sut1, sut2);
}

DomainEntityBase, test 2:


[Test]
public void TwoInstance_DifferentIdInput_AreNotEqual()
{
    var sut1 = new DomainEntityBase { Id = 123512 };
    var sut2 = new DomainEntityBase { Id = 64236 };

    Assert.AreNotEqual(sut1, sut2);
}

DomainEntityBase, test 3:


[Test]
public void TwoInstance_ZeroIdInput_AreNotEqual()
{
    var sut1 = new DomainEntityBase { Id = 0 };
    var sut2 = new DomainEntityBase { Id = 0 };

    Assert.AreNotEqual(sut1, sut2);
}

Invoice_Money_LineItems, test 1:


[Test]
public void Constructor_NoINputs_IsInstanceOfDomainEntityBase()
{
    var sut = new Invoice();
    Assert.IsInstanceOf(typeof(DomainEntityBase), sut);
}

Invoice_Money_LineItems, test 2:


[Test]
public void Constructor_NoINputs_IsInstanceOfDomainEntityBase()
{
    var sut = new LineItem();
    Assert.IsInstanceOf(typeof(DomainEntityBase), sut);
}

Invoice_Money_LineItems, test 3:


[Test]
public void Constructor_AmountAndCurrencyInputs_MatchGetterProperties()
{
    const decimal amount = 3.25M;
    const string currency = "CDN";
    var sut = new Money(amount, currency);

    Assert.AreEqual(amount, sut.Amount);
    Assert.AreEqual(currency, sut.Currency);
}

Invoice_Money_LineItems, test 4:


[Test]
public void Constructor_AmountAndCurrencyInputs_AreReadOnly()
{
    const decimal amount = 3.25M;
    const string currency = "CDN";
    var sut = new Money(amount, currency);

    Assert.IsFalse(sut.GetType().GetProperty("Amount").CanWrite);
    Assert.IsFalse(sut.GetType().GetProperty("Currency").CanWrite);
}

Invoice_Money_LineItems, test 5:


[Test]
public void TwoInstances_SameCurrencyAndAmountInputs_AreEqual()
{
    const decimal amount = 3.25M;
    const string currency = "CDN";
    var sut1 = new Money(amount, currency);
    var sut2 = new Money(amount, currency);

    Assert.AreEqual(sut1, sut2); // use struct for default "all-class-members" equality
}

Invoice_Money_LineItems, test 6:


[Test]
public void LineItemsProperty_Getter_IsReadOnlyCollection()
{
    var sut = new Invoice();
    Assert.IsInstanceOf(typeof(IEnumerable<LineItem>), sut.LineItems);
}

Invoice_Money_LineItems, test 7:


[Test]
public void AddLineItemsMethod_LineItemInput_IncrementLineItemsCollection()
{
    var sut = new Invoice();
    Assert.AreEqual(0, sut.LineItems.Count());

    sut.AddLineItem(new LineItem { ProductCode = "aaa"});
    Assert.AreEqual(1, sut.LineItems.Count());
}

Invoice_Money_LineItems, test 8:


[Test]
public void AddLineItemsMethod_SameLineItemTwiceInput_DoesNotIncrementLineItemsCollection()
{
    var sut = new Invoice();
    var lineItem = new LineItem { Id = 3522, ProductCode = "aaa" };

    sut.AddLineItem(lineItem);
    Assert.AreEqual(1, sut.LineItems.Count());
    sut.AddLineItem(lineItem);
    Assert.AreEqual(1, sut.LineItems.Count());
}

Invoice_Money_LineItems, test 9:


[Test]
public void AddLineItemsMethod_LineItemInput_InvoicePropertyMatchesParent()
{
    var sut = new Invoice();
    var lineItem = new LineItem { Id = 3522, ProductCode = "aaa"};

    sut.AddLineItem(lineItem);

    Assert.AreEqual(lineItem.Invoice, sut);
}

Invoice_Money_LineItems, test 10:


// Given an existing LineItem, when I try to add a LineItem without a ProductCode,
// then I am informed that I must provide a ProductCode.
[Test]
[ExpectedException(typeof(InvalidLineItemException), ExpectedMessage = "You must provide a ProductCode")]
public void AddLineItemsMethod_LineItemWithoutProductCode_ThrowsException()
{
    var sut = new Invoice();
    var lineItem = new LineItem { Id = 3522 };

    sut.AddLineItem(lineItem);
}

Branch-Per-Feature using the Total Integration Total Isolation Principle

2011-07-17T12:55:00.000-07:00

I posted this originally as a comment on a Google Plus thread here which has a more complete discussion on ideas (and disagreements) regarding Branch-Per-Feature and Continuous Integration.

The purpose of this entry is to focus on how a principle of Total Integration and Total Isolation shapes the approach taken to branch-per feature.

*****

In this approach, all of the following are givens:

1) releases occur on a regular basis, and development is oriented to the release schedule

2) releases coincide with merge to master

3) the release is tagged, and an empty commit immediately following the release commit is also tagged (as the start of the new cycle)

4) the existing integration ("dev") branch and the qa branch from last cycle are now re-pointed to the new start-of-cycle tag

Key point here: master is ONLY updated once per release, at the point of release--but the integration/dev and qa branches originate from (and are therefore identical to) master

The process now begins, which adheres to a "Total Integration Total Isolation" principle

1) Each developer chooses a ticket and creates a branch with that number (eg. In JIRA, tickets ABC-141, ABC-142, ABC-143, ABC-144)

2) This branch will be short lived (it won't live past the release of the ticket) although the actual commits will be preserved.

3) The developer commits frequently their branch (eg. ABC-143).

4) However, as per some of the heated discussion in this thread, the developer also merges every few hours with the integration/dev branch and checks for conflicts, compile fails, and runs all tests either locally or via the CI server's integraton/dev branch build.

5) Merge conflicts are resolved (and cached for future reuse if the DVCS permits), but outright failures requires the dev to go back to their feature branch and make the fix there, before re-attempting the merge to integration/dev branch.

6) Note that the feature branches never merge FROM the integration branch, because this would violate the isolation side of the Total Integration Total Isolation principle.

7) What about major refactorings or new archicture/scaffolding that one or more features need to share? In that case, a new ticket (eg. Dev task ABC-145) is created to hold that shared work and a branch is created (again, off of the start-of-cycle tag) to hold that major refactoring or scaffolding. The features requiring this branch change their start point/dependency from the start-of-cycle tag to this refactoring/scaffolding branch and they will retain this dependency until the end of the release.

8) Going forward, each new work is commited only to the feature branch, and each feature branch is regularly merged to integration/dev. This results in the Total Integration Total Isolation goal

9) Since every branch now originates from start-of-cycle (or from a shared refactoring/scaffolding branch that originated from start-of-cycle), QA can now safely pick and choose which features to merge onto the qa branch, and ultimately, which to release and merge to master.

10) Any features that were not released can be discarded (if rejected entirely) or rebased onto the next start-of-cycle tag (if to be resumed).

Branch-Per-Feature: Successful Transitions/Cleanup Between Sprints

2011-07-01T18:08:00.000-07:00

.

Introduction
Branch-per-feature is the discipline of beginning every feature branch for a given sprint off exactly the same commit (typically, the first commit of the sprint). The strict enforcement of isolation between features quickly reveals the bad habits of dependencies we build between multiple features, and forces us to ask the right questions of how to keep our features independent.

Some benefits of branch-per-feature:

dev: proper isolation of code changes; breaking bad habits of code dependencies between branches
dev: embracing granularity of code changes
dev/QA: (almost) painless merging
QA: ability to assemble a release made up only of branches that are ready

(For more details, see: Branch-Per-Feature using the Total Integration Total Isolation Principle.)

Successful Transitions (Cleanup) Between Sprints
The focus of this blog post is more narrow: to define the steps involved in successful transitions between sprints/releases when using branch-per-feature to manage the release.

We've been working out the logistics for this recently at work, under the guidance of @martinaatmaa and @adymitruk. What this looks like:

Over the course of a given sprint, each feature is branched off a common commit from the start of the sprint. As each feature reaches a point of stability and completion, it is merged back into an integration branch (named something like projectname-dev). When qa is ready to test, all features to be tested are folded into a qa branch (named something like projectname-qa). Upon release, the projectname-qa branch is merged into master, and tagged as the release branch for that sprint. Now that the code has been released, the feature branches for that sprint are no longer required. They are cleaned up (deleted), although the underlying commits are kept.

Examples and screenshots illustrating this process are shown below.

To begin the next sprint, a new empty commit is created and tagged something like start-sprint2. Each feature is created off that starting commit.

Scaffolding
Early in the sprint, if it is determined that a scaffolding commit is necessary to hold some common architecture to be used by all features, a new scaffolding-only feature is created for that purpose. The scaffolding feature branch becomes the new starting point of the commit, with all features branching off that pre-requisite feature.

Feature Branch Naming
The tools we are using to achieve this are git and JIRA (with the Greenhopper plugin). For feature branch naming, we use the JIRA ticket names. For example, a project whose tickets are named PAYGATE-265, PAYGATE-286 would have corresponding git feature branch names (paygate-265, paygate-286).

Note If a scaffolding feature is required in the sprint, the scaffolding branch will have a normal branch name (paygate-262) and all subsequent commits can indicate the dependency in their name (paygate-265-d-262, paygate-286-d-262).

Practise Scenario
To practise my skills in branch-per-feature at home, I've been using Ubuntu, rails, git, and a local install of JIRA/Greenhopper. The project used for this practise is the book Ruby on Rails 3 Tutorial. I've broken out the chapter contents into individual features as JIRA tickets. The JIRA project is broken up into very small sprints (1 weekend worth of work per sprint, probably 4-6 hours at most.)

The rest of this blog entry demonstrates branch-per-feature using this simple project, as we fold the features of sprint 1 into an integration branch, then a qa branch, and finally a release branch. We then clean up the old branches and begin work on sprint 2 features, with each one branching off the starting commit of sprint 2.

Here is a screenshot of sprint 1 in JIRA. Each ticket in this sprint has been implemented as a feature branch in git:

To complete the sprint (and its related release), I perform 3 steps:

merge all the tickets into the integration branch (rails-dev) and test the code
upon success, merge all passing features into the QA branch (rails-qa) and test the code
upon success, merge rails-qa into master and tag it as the release.

Here's the gitk view:

With the sprint completed, its time to go back to JIRA (with Greenhopper plugin) to verify that everything in sprint 1 is closed, and that remaining story points are at 0, followed by setting up and prioritizing sprint 2:

Now that sprint 2 is prepared, its time for the dev team to begin coding. I switch to the JIRA/Greenhopper task board view, and drag my first ticket LRNRAILS-15 to In Progress:

To begin work on the dev tickets, we need to first set up the new sprint 2 in git. I begin by creating an empty commit off the release/master branch. To do this, I checkout the tag release-lrnrails-sprint1 (or master branch). To create the new commit of an empty branch:


git commit --allow-empty

I then tag it with a name such as start-lrnrails-sprint2.


git tag start-lrnrails-sprint2

Since this is the commit that all features will originate from, I will also move my integration (rails-dev) and QA branches (rails-qa) to this commit (by checking out eadch branch and then using git reset --hard start-lrnrais-sprint2 to point them at the starting commit).

Finally, we need to CLEAN UP (remove) all of the sprint 1 feature branches as they are no longer needed. At work we relied on @adymitruk's bash scripts to construct the delete commands that clear out both the local and remote branches. I tried this with my project at home, and got it to work successfully.

For example, given that I want to delete branch jira-lrnrails-5, my local and remote commands would be:


git branch  -D jira-lrnrails-5
git push origin :jira-lrnrails-5

To achieve this for all branch-per-features which were merged into the release, I checkout the release-lrnrails-sprint1 tag (or master branch), and then run the following commands, first as preview (using echo to verify the commands):


git branch --merged | grep lrnrails -i | xargs -i{} echo git branch -D {}

and then the actual execution of the commands:


git branch --merged | grep lrnrails -i | xargs -i{} git branch -D {}

Then, the same for the remote branches:


git branch -r --merged | grep lrnrails -i | cut -d '/' -f 2 | xargs -i{} echo git push origin :{} 
git branch -r --merged | grep lrnrails -i | cut -d '/' -f 2 | xargs -i{} git push origin :{}

Now, with all of the branch-per-features deleted for sprint1, the view is much cleaner in gitk:

Now I am ready to begin work on sprint 2. I checkout the starting point commit for this sprint:


git checkout start-lrnrails-sprint2

and then create my feature branch off that starting commit:


git checkout -b jira-lrnrails-15

I then proceed to write the code for this feature. At a certain point, I will do one-or-more commits for this feature branch:

git add . -A
git commit -m "LRNRAILS-15 Adding variables to the views"

With the feature branch commited, I am ready to test my integration branch for the first time. I check out the integration branch (myprojectname-dev) and then do a git merge --no-ff against the new feature branch:


git merge --no-ff jira-lrnrails-15

This gives me my first integration branch merge of sprint 2:

From here, the second (and subsequent) sprints can move forward using branch-per-feature to properly isolate code changes, and to enable QA to assemble release packages based on a specifically chosen subset of verified features.

Programming in sprint cycles (currently sprint 9)

2011-03-19T17:52:00.000-07:00

This post is meant to be a bit more observational than my usual how-to posts. It describes what my first experiencing of programming in agile sprints has been like.

The sprints are set up on a weekly basis, starting on Thursday mornings with a demo to the stakeholders of the completed user stories of the just-completed sprint. Each demo is guided from a list of (JIRA-based) tickets stored in a spreadsheet. Read out the ticket name, go over the acceptance criteria, hide the spreadsheet, and demo the completed feature. The demos are recorded in Camtasia the day before, and stored online for ease of access by all members of the team for later reference (eg. an additional stakeholder added, or a team member back from 2 weeks vacation.)

With the demo completed, a sprint retrospective is held, guided by our team lead / SCRUM person. We go into more or less detail, depending on the week. (I've found this process to be amazingly clarifying and effective.) We then launch JIRA, go into the planning view, add any additional stories/tasks/bugs that have become evident, assign any unassigned tickets, and place them in likely order of completion. We then go through each ticket and give it a story point rating. This rating has been much easier to arrive at with each subsequent sprint. We look at the total story points, knowing what our average velocity has become per sprint, and either push tickets back to the later sprint, or perhaps bring tickets forward into the current sprint if we are a bit short.

By this point it is typically noon, so we grab some lunch. After lunch I go to my desk, launch JIRA, flip into task board view, and look at my backlog. I drag over (typically the top) item. Most of the time, I try and keep only one item in the active development swimlane (although by the end of a busy day (several smaller story-point tickets may have traversed from backlog to development to tech review).

I'm now ready to start, so I launch git bash, change to the git repo containing the area where I need to work (typically web applications, with a submodule to shared libraries). I do a git fetch to get the latest, checkout the dev branch, and do a git merge --ff-only origin/dev if necessary to catch up to latest. I think create a local branch on that commit, typically with the JIRA ticket number in the branch name, something like prd1234addMissingNullCheckGuardCondition (I've always liked long descriptive branch names or for that matter, method names in code, since tab in git or Intellisense in VS will be happy to save the typing effort for me later).

At this point, I try and gain an understanding of what's needed. Before long, I'll be creating an NUnit test. The test may be in a Nnnn.Tests.Unit project or Nnnn.Tests.Integration project, depending on the legacy code situation and the ability (or inability) to substitute dependencies. The general rule of thumb at the moment is that if it is new functionality altogether, or if it is abstracting/creating utility or helper classes that work with the legacy code, then unit tests will be possible. For new functionality, dependencies are DI injected and tested with mocks or just simple fake implementation classes.

When the work is completed, I do git fetch again, fast-forward the dev branch if new work has been added, swtich to my local branch, rebase it onto the dev branch, switch to dev branch, merge in my local branch, check the results in gitk --all GUI view, and if everything looks clean, push it to origin. I do this in the submodule / shared libraries first, and then again at the outer level. This push to origin is picked up on by the TeamCity integration server, and for the current project that typically means I want to wait for TeamCity to create the artifact (a combination of pages and xcopy-deploy style DLLs whose structure I have setup and verified on TeamCity awhile back). When TeamCity, compiles, passes all tests, and generates the artifact successfully, I save the artifact zip file to the web server, unzip it, move it to the deploy directory, update the permissions, and repoint the IIS home directory for that project to the new artifact.

With that complete, I drag the ticket from the development swimlane to the tech review swimlane, alert QA that it is ready, typically verbally, often supplemented with an explanation either in JIRA or just in email, and look to my backlog for the next ticket.

This is of course interrupted constantly by emails, discussions, whiteboard sketch sessions, morning standup, and afternoon coffee runs, but in the midst of daily chaos, the ongoing process of the tickets moving across the swimlanes gives a steady rhythm to the week.

We're in sprint 9 now, and probably one more sprint will finish this project. Another project is in the works. This is a most interesting, satisfying, and fascinating process.

Using git submodules to share a backend library between two local repositories

2010-09-19T14:55:00.000-07:00

Acknowledgements
The following knowledge about git submodule usage has been achieved from on-site training with Adam Dymitruk. (Also, be sure to check out Adam's article in Code Magazine: Git from a Developer's Perspective.)

What scenario is this blog entry meant to address?
This blog entry addresses the common scenario where multiple web, Windows, Silverlight, console, or other clients all reference a common set of backend libaries. The backend libraries would contain the domain model, repository layer, utils, external gateway references, and so on.

Why git submodules?
git submodules present a distinct advantage over other methods for referencing backend libraries. Let's look at some of the alternate approaches generally used.

Approaches for referencing backend libraries from multiple clients

Referencing compiled DLLs (via file directory or GAC).
Referencing a web proxy (where backend libraries are deployed via a web services layer).
Referencing the .csproj files from a single location in your file directory
Referencing the .csproj files from multiple locations (one per local git repository)

This last approach uses git submodules.

Let's have a more detailed look at each approach:

Referencing compiled DLLs
In this case, you treat the backend libraries as a somewhat fixed SDK, much as you might treat a 3rd party library. In debug mode, your breakpoints end at the boundary of the compiled DLL.

Referencing a web proxy
You build a Remote Facade over the domain, in which all possible domain interactions are encapsulated in coarse-grained service methods. You then expose this layer as web services, and in your clients, create web services proxies, which you then reference. In debug mode, your breakpoints end at the boundary of the web service proxy.

Referencing the .csproj files from a single location in file directory
You wish to debug right from the client through to the backend, so you reference your backend libraries in two distinct ways:

In standard fashion, you have a solution file for the backend libraries themselves, within the enclosing folder. This solution also includes various unit/integration test projects for building / validating your backend libraries.
However, your external clients ALSO reference one or more of the library/projects as .csproj files, within your local client solution file.

This last solution provides the benefit of pass-through debugging, but it quickly presents an obvious problem: you have multiple clients, in different stages of development. What if one client needs 'release 1.8' version of the backend libraries, but another client needs 'release 2.0' version of the backend libraries? (And that's not even getting into hot fixes!)

Which brings us to the 4th approach:

Referencing the .csproj files from multiple locations (one per local git repository)
The following diagram demonstrates the file directory configuration for this approach:

In this last scenario, each local git repository (a grouping of client projects, based on some common organizing principle determined by your organization) has a local copy of the backend libaries stored WITHIN that local repository. The benefit provided is that each copy of the backend libaries can exist in a different state (i.e. at a different point in the git commit history, pointing at a different branch.)

Here's what that might look like for you on some future Tuesday at work:

In the morning, you are working on the SilverlightClientApps local repository, on ClientApp2. For this you require the backend libaries in release1.8 branch.
In the afternoon, you are working on the WebClientApps local repository, on ClientApp5. for this you require the backend libraries in hotfix_2010Oct branch.

And even that scenario is keeping it very simple--there's no reason you can't create a local branch of the backend libary to make some custom changes as you go--but lets start with the simple scenario, for now.

Steps to setup a git submodule
Let's assume you are starting by installing git. We'll then make 3 local libaries: WebApps, WinApps, and BackendLibaries. We'll turn each one into a git repository, store them all in a fake local server (which is good enough for our purposes at the moment), and then setup additional local copies of the BackendLibaries as submodules with distinct commits, in each local repository (i.e. WebApps and WinApps).

Do the following:

Install git if you don't have it already installed.
Launch GitBash.
Create a local directory called /c/dev/
As per the following screenshot, set up myGitSubmoduleDemo with 3 subdirectories for webApps, winApps, and backend Libraries

Go to the webApps subdirectory, and set it up as a local git repository, with a single commit, and set to the dev branch:

Repeat for the winApps directory

And finally, repeat for the backendLibraries, but with 2 release branches

Next: you need to set up all 3 local repositories as server repositories. In this example, you simply create a local directory at /c/MyFakeGitRepositoryServer/, and make a bare clone of each local repository in this location.

Now return to your local repositories, and use the "git remote add origin" command to connect your local repository to each server repository

Congratulations! You are now ready to create a submodule within each client repository (webApps and winApps). Let's start by creating the submodule within webApps

Note that in the last step, you change directory from the outer directory, "webApps" to the inner directory (the submodule) "backendLibraries". Notice that these directories are in completely different branches. Other than relative placement, they are INDEPENDENT. You can edit either the outer client repository or the inner submodule, you could add commits to either one, change branches, or do any other git action should you choose; but these are independent local repositories, and your actions in each are separate and independent.
Now let's repeat the above steps for the "winApps" local repository:

And finally, just to make the point perfectly clear: let's make a NEW branch on this copy of backendLibraries, add a new file within this branch, and commit it:

Note that this new branch is on the backendLibraries submodule, WITHIN winApps. The enclosing local repository winApps is unchanged (still within dev branch). Go up one level to the winApps branch, and type "git status" to check your status.

The git status commands does observer some changes, but these are all EXTERNAL changes, about the submodule itself: it sees that a submodule has been added (along with a .gitmodules configuration file); and it can tell that backendLibaries has been modified. But it knows nothing about the changes within the backendLibraries submodule, because that is not within its scope. You are now managing, two, separate local repositories, one of which happens to be nested as a submodule within the other.

Conclusion
Does having two, independent copies of the backendLibaries in each local repository remind you of anything? It should: this scenario is indistinguishable from having two developers, on two separate machines doing branching, commits, merges, and checkins (git push) on local copies of backendLibraries. It just happens that in this case, those two local developers are both YOU: you, in the morning, working on some webApps and the backendLibraries submodule within webApps; and you, in the afternoon, working on some windowsApps and the backendLibraries submodule within windowsApps.

In conclusion, the main benefits of git submodules (as implemented in the above scenario) are twofold:

You can use direct .csproj references to your backend Libraries in your client apps.
You can maintain independent (and diverging) branches of those backend Libraries in each local git repository that you configure with a backendLibraries submodule.

Combining TDD kata with git branching and merging

2010-08-28T14:54:00.000-07:00

I've been learning from Adam Dymitruk recently how to do git branching and merging from the command line. I thought I would codify some of this in a blog post. Since I also am interested in TDD kata, I'm going to try combining the two into a shared TDD/git kata.

To do this, I'll take the first couple of tests from Roy Osherove's Calcualtor kata, and combine them with the practice of git branching and merging. You really don't want to do this unless you already have some comfort with doing Calculator kata; if you are new to the Calculator kata (or to TDD generally) this git configuration will only prove to be a distraction.

However, if you are already comfortable doing the Calculator kata, and want to work on git branching and merging, this will provide some practice.

This blog entry assumes you have the following installed:
* git and the GitBash command-line tool
* Visual Studio 2008 or 2010
* Resharper

This WON'T assume you have access to a git repository on a server, we will fake a "git repo server" on your local hard drive instead.

Setup
1) On your local drive, create a folder to represent your fake git repo server, named something like:

c:\FakeGitRepoServer

2) Add a .gitignore file to the root of this directory. The .gitignore file instructs git which configuration files can be ignored/not stored in git. You can create one from this StackOverflow discussion thread. Paste the contents into NotePad, and then save it as c:\FakeGitRepoServer\.gitignore

NOTE You don't NEED it here for the repository. This is just a convenient place to store it. You'll be copying into each project folder as part of your git configuration.

3) Launch Visual Studio 2008/10 and create a new solution named "TDDKata_Calcuator_2010Aug28" with two class libraries:

MyCompName.Kata.Domain
MyCompName.Kata.Tests.Unit

3) Add a reference to NUnit.Framework (in the tests project).

4) Launch GitBash.

5) Use the cd command to change to your solution directory. For this blog entry, let's assume that location is:

c:\SourceCode\dotNet\TDDKata_Calculator_2010Aug28\

NOTE The examples in this blog post use relative pathing to move around. Some people find this tiresome. If you'd like a simple alternative, you can specify your paths from the drive root. For example, assuming you are using the C: drive, you could use commands such as:
cd /c/SourceCode/dotNet/TDDKata_Calculator_2010Aug28

6) Any new folder that isn't yet set up for git must first be initialized for git. Type: "git init"

You'll observe that the path now includes a branch name, "master" in brackets at the end of the path. In this git/TDD kata, we'll be creating additional branches: a permanent branch named "development", and any number of temporary, feature branches, with names like "myFirstTest". These branches will be merged back into the development branch and discarded as each minor feature reaches a relative degree of solidity (the test passes) and we are ready to move on. No matter how many temporary feature branches we create, we will always return back to (and merge into) the development branch.

NOTE At the very end of the kata, we will merge the development branch back into the master branch. This is analagous to deployment to production.

NOTE For a definitive article on git branching for team development, see the article A Successful Git Branching Model.

8) But first things first: Let's get a local copy of our .gitignore file, something we should always do immediately after initializing the folder. To copy the .gitignore file from the folder where you stored it earlier to your current folder, type:

cp ../../../FakeGitRepository/.gitignore .

9) Now that git knows which files to ignore, let's have a look at your current situation. Type 'git status'

10) From here, going forward, for basic git checkin, you will use the same 4 git commands over and over:

git status // this updates you on the file status
git add . -A // this adds the files to be tracked
git commit -m "my comment" // this commits the file
git push // this moves the commit to the remote repository

11) Let's start by adding the files:

11) Now let's commit those files:

12) At this point, you need to push these files to the git remote repository on the server--but we haven't set that up yet! To do this, change directory to the c:\FakeGitRepoServer:

cd ../../../FakeGitRepository

13) In that directory, create an empty copy (a "bare clone") of your local git directory. The syntax for this is:

git clone --bare ../SourceCode/dotNet/TDDKata_Calculator_2010Aug20/.git

13) Now you can return to your local repository, set up a connection to the new remote repo, and push your files to that repo. To return to your local repository, type:

cd ../SourceCode/dotNet/TDDKataCalculator_2010Aug28/

14) Now, from your source directory, to set up a connection to your remote repository, enter:

git remote add origin /c/FakeGitRepoServer/TDDKata_Calculator_2010Aug28.git

15) As above, you can VIEW your remote settings with:

git remote -v

16) It took awhile to set up that repository--where were you before you started that? -- You were about to push your local commit to the remote repository. Let's do that now:

git push origin master

17) Congratulations--you have your Calculator kata started, and your first set of code changes have been:

committed
pushed to the master branch on the remote repository

18) Now it's time to learn a little about branching. Our primary branch will be development, so we'll switch to that branch now. We only will merge back development into master branch at the very end of this kata (think of it as final release to production). Enter:

git branch development

git checkout development

Excellent! Setup is complete, we're ready to begin the kata!

TDD Calculator kata with branching and merging

1) Create a new "feature" branch for your first test:

git branch firstTest

git checkout firstTest

2) The git command line should now show that the current branch is firstTest:

3) Switch to Visual Studio, and create your first test. Something like this:

4) Use Resharper to create the Calculator class and move it to the Domain class libary; and get the test to pass.

5) Now use the following 4 commands to checkin your code to your feature branch:

git add . -A
git commit -m "First test created and passes"
git push origin firstTest
git status

6) Note that when you push your code to the remote repository, that you are pushing it to a parallel branch (firstTest) in the remote repository. This is created on the fly by git if it doesn't already exist.

7) Go back to Visual Studio and run your test again, it should pass.

8) Now return to git, and switch to the development branch:

git checkout development

9) When you return to Visual Studio, you will be asked to Reload screens. Do so.

10) Try running your test. Note that the code has disappeared! This is because the code exists only in your firstTest feature branch at the moment. Since you know the code is solid (the test is passing), it is safe to merge it back to dev. Let's do so:

git merge firstTest

11) Your changes are now merged. Switch to Visual Studio, and reload. (If Visual Studio seems confused about folders or .csproj files, just close and re-open the solution).

12) You should now be able to run your first test while in the development branch; in other words, you have confirmed that the merge was successful.

13) You don't need the feature branch anymore, so delete it:

git branch -d firstTest

14) Would you really create and delete a feature branch for a single test? Probably not; you'd probably do a series of tests to flesh out the feature, then merge them, then delete the feature branch. But the purpose, as always, with a kata is to get comfortable practicing a process and making it intuitive. So let's proceed to create a temporary feature branch for the next for kata tests.

15) Create a new feature branch named secondTest.

git branch secondTest
git checkout secondTest

16) Switch back to Visual Studio, and create your second test, something like:

17) Once again, modify your code until the test passes.

18) Once again, run the following 4 commands to checkin your code and push it to the remote repository (under the feature branch secondTest):

git add . -A
git commit -m "Second test created and passes"
git push origin secondTest
git status

18) Once again, go to git and checkout the development branch:

git checkout development

19) Once again, return to Visual Studio and note that your second test has disappeared.

20) Once again, return to git and merge the branches. (This time, try adding the tag --no-ff, which stands for no-fast-forward. This leaves a little more merge history in your record to view later as necessary):

git merge secondTest --no-ff

21) Once again, go to Visual Studio and confirm that your second test is running (i.e. has been merged) within the development branch.

22) And finally, once again, delete the feature branch secondTest since you no longer need it:

git branch -d secondTest

23) Continue creating feature branches for several more tests. When you are done, as your final step, checkout the master branch, and merge all the changes your have made in the development branch to the master branch.

Conclusion
In this kata you have been familiarizing yourself with the process for combining the TDD process with the git feature branching and merging process.

The key takeaway is the understanding of using git branching as a dynamic process for development, which can be learned effectively as part of working through a TDD kata process that you are already familiar with.

TDD Brownfield example: refactoring a large procedural method to Dependency Injection

2010-07-25T17:48:00.000-07:00

It's not uncommon when doing Brownfield TDD to encounter legacy procedural code that is doing multiple distinct actions within a single method. Let's go with a hypothetical example:

"An ASP.NET website has a button_click event handler which does the following:
a) calls to a legacy COM+ object
b) calls to a 3rd party licensed DLL
c) calls to a web service
d) calls some ADO.NET code to save to a database
The method is approximately 100 lines of code and is, in its current form, untestable."

How might you break this down, with some minimal refactoring but without actually changing any of the functionality of the 4 actions within the event handler, to make it testable?

Here is one possible approach:

Begin with Refactoring
1. Do Extract Method refactoring on the event handler to move the code into a seperate method.
2. Use Extract Class refactoring to move this method to a separate class.
3. For testability, this logic needs to be in a separate class library, not in the context of an ASP.NET website, so do the following:
     a) create a new project in your solution, of type class library, and name it (eg. Web.Support)
     b) move the new class you have created into this project.
     c) fix any compiler errors by referencing the new class library and then adding a using statement to the code-behind class.
4. In the new class library, Add References to resolve any compiler errors within the class.
5. Most typically, this will be a reference to System.Web (plus any custom or 3rd-party references your page was using).

NOTE For broken references to Session, use: System.Web.HttpContext.Current.Session

5. Finally, within this new external method, use Extract Method refactoring to break out the 4 unique pieces of functionality into 4 public methods that can be called separately.

When you are done, you should have something like this:


public class MyExtractedClass
{
     public void MyExtractedButtonClickEventHandler()
     {
          // various parameters declared here

          CallToLegacyComObject(); // each metod will have various parameters
          CallToThirdPartyDLL();
          CallToWebService();
          CallToAdoNetDbSave();
     }
}

You are now ready to begin creating your unit and integration tests against a coordinator class. This class will coordinate each of the pieces of above functionality, but in the form of interfaces. Each interface will represent a distinct part of the functionality that can be tested separately. Typically in an ASP.NET (WebForm) web site this coordination is achieved using Model-View-Presenter, where the Presenter is a class that will coordinate the various interfaces. These interfaces are made available to the presenter class by "injecting" each interface into the class as a parameter to the class constructor (hence the term: Dependency Injection.) In this case, you are going to have 5 interfaces injected into the presenter class: one for each unique piece of functionality, plus the view interface.

Creating the Unit Test
1. Create two new class library projects:

Tests.Unit
Tests.Integration

2. To each project, add references to NUnit.Framework and Rhino.Mocks
3. Class variables: you being by declaring repository interfaces for each of the functionality elements you need to test. Note that the names of these interfaces should not reflect the technology--for example, IComPlusObjectRepository is a bad name because at the interface level, one does not know whether COM+ will be used as an implementation. Instead, the names of the interfaces should reflect WHAT the functionality business logic does. Let's rewrite the above 4 method calls as pseudo-code, to define WHAT they actually do:


public class MyExtractedClass
{
     public void MyExtractedButtonClickEventHandler()
     {
          // various parameters declared here

          // 1. get gym membership fee structure
          // 2. parse and write a PDF invoice
          // 3. register details with national gym organization
          // 4. save gym membership changes to db
     }
}

4. Now that you have an idea of what they do, name your repository interfaces names such as:

IGymMembershipFeeRepository
IPdfInvoiceParserRepository
INationalGymRegistrationRepository
IGymMembershipRepository

5. The presenter class: typically you will create one presenter per ASPX page, so it makes sense to use a naming prefix similar to the ASPX page (assuming the ASPX page has a more meaningful name that Default.aspx). Since it appears that the purpose of the original button_click event was to process gym membership fees, you might name your presenter class something like GymMembershipPresenter, with a unit test class name of GymMembershipPresenterTests.cs

6. In the Web.Support class library, you will now need new sub-namespaces for each of these interface or class types. To do this, create the following folders within the class library:

Repository
Presenter
View

7. Now we have enough knowledge and infrastructure to create our first unit test in the new project Tests.Unit. The test will make use of interfaces, a presenter, and mocks (mock implementations) to experiment with the interaction design. Let's see what this code might look like (just scan it briefly if you are new to mock objects, then read the explanation below).

NOTE We create the unit test BEFORE the interfaces or classes exist, so we won't have Intellisense assistance as we type out these interface or class names as they do not exist yet. The compiler will flag these in Visual Studio by marking them in red. You can then implement these classes in multiple ways:

manually
make use of the Generate by Usage feature in Visual Studio 2010
install a tool like Resharper to enable you to generate these classes more quickly

 [TestFixture]
public class GymMembershipPresenterTests
{
    private MockRepository _mockRepository;
    private IGymMembershipFeeRepository _gymMembershipFeeRepository;
    private IPdfInvoiceParserRepository _pdfInvoiceParserRepository;
    private INationalGymRegistrationRepository _nationalGymRegistrationRepository;
    private IGymMembershipRepository _gymMembershipRepository;
    private IGymMembershipView _startTransactionView;

    [SetUp]
    public void SetUp()
    {
        _mockRepository = new MockRepository();
        _gymMembershipFeeRepository = _mockRepository.StrictMock<IGymMembershipFeeRepository>();
        _pdfInvoiceParserRepository = _mockRepository.StrictMock<IPdfInvoiceParserRepository>();
        _nationalGymRegistrationRepository = _mockRepository.StrictMock<INationalGymRegistrationRepository>();
        _gymMembershipRepository = _mockRepository.StrictMock<IGymMembershipRepository>();
        _gymMembershipView = _mockRepository.StrictMock<IGymMembershipView>();
    }

    [TearDown]
    public void TearDown()
    {
        _mockRepository.VerifyAll();
    }

    [Test]
    public void Constructor_FiveRepositoryInputs_ConfiguresGymMembershipAndReturnsMessage()
    {
        const string name = "Sally Wong";
        const decimal amount = 35.00M;
        GymMembership gymMembership = new GymMembership { Name = name, Amount = amount };
        Expect.Call(_gymMembershipFeeRepository.CreateMembershipFee(name)).Return(gymMembership);

        InvoicePdf invoice = new InvoicePdf { GymMembership = gymMembership };
        Expect.Call(pdfInvoiceParserRepository.CreatePdf(gymMembership)).Return(invoice);

        NationalGymInfo nationalGymInfo = new NationalGymInfo { ResponseCode = "<out>some expected xml</out>" };
        Expect.Call(nationalGymRegistrationRepository.RegisterDetails(gymMembership.Name, gymMembership.Amount)).Return(nationalGymInfo);

        var gymMembership = new GymMembership
                                                       {
                                                           Name = name,
                                                           LockerNumber = 352,
                                                           Amount = amount,
                                                           NationalGymInfo = nationalGymInfo
                                                       };
        _gymMembershipRepository.Save(gymMembership);

        _gymMembershipView.Message = "Your membership has been processed.";

        _mockRepository.ReplayAll();

        var sut = new GymMembershipPresenter(_gymMembershipFeeRepository,
                                    _pdfInvoiceParserRepository,
                                    _nationalGymRegistrationRepository
                                                         _gymMembershipRepository,
                                    _startTransactionView);
        sut.CreateNewGymMembership(name, amount);
    }
}

Explanation of the Unit Test with Mocks
For a complete explanation of mock objects, there are many good resources on the web. However, the MAIN purpose of a unit test that uses mock objects is for DESIGN. As you create this unit test, you are designing (experimenting with) possible interactions in the presenter class, using mock versions of the interfaces to speculate what those interface implementations might do, and what values they might return back.

Typically the unit test consists of the specifying mock behaviors (using the Expect() method of Rhino.Mocks for methods or properties that have a return type), following by the ReplayAll() command, followed by the actual presenter instantiation and method call (see above code snippet for exact details.) The [TearDown] method then calls the VerifyAll() command to validate the specification.

Once you start to run the unit tests, the mock object framework will validate the specification and point out where the REAL presenter class doesn't yet match the specification you have created with your mocks. This becomes a trial and error process where you keep adding code to the presenter until all of the expectations which you have set up in your unit test have been satisfied by the presenter.

Why is this important? Why go to all this work to specify the interface interactions within the presenter? Because one you have established a working unit test, you are now in a position to create integration tests where each element can be tested independently.

Integration Tests
You can now create an integration test that ONLY tests the behavior of the COM+ object; the rest of the interfaces can be implemented with a "fake" class whose only purpose is to pretend to succeed. This allows you to focus each integration test on the real behavior of a single interaction.

8. Add a new integration test class to the Tests.Integration class library, named GymMembershipPresenterTests.cs (it will show up under the integration test library so the name can be the same, or different.)

9. Note the code below. For integration tests, we don't have to use a mocking framework. Instead, we create fake classes, whose only purpose is to succeed happily. The first integration test will simply pass by calling all fake classes.


[TestFixture]
public class GymMembershipPresenterTests
{
    private IGymMembershipFeeRepository _gymMembershipFeeRepository;
    private IPdfInvoiceParserRepository _pdfInvoiceParserRepository;
    private INationalGymRegistrationRepository _nationalGymRegistrationRepository;
    private IGymMembershipRepository _gymMembershipRepository;
    private IGymMembershipView _startTransactionView;

    [SetUp]
    public void SetUp()
    {
        _gymMembershipFeeRepository = FakeGymMembershipFeeRepository();
        _pdfInvoiceParserRepository = FakePdfInvoiceParserRepository();
        _nationalGymRegistrationRepository = FakeNationalGymRegistrationRepository();
        _gymMembershipRepository = FakeGymMemberhipsRepository();
        _gymMembershipView = FakeGymMembershipView();
    }

    [Test]
    public void Constructor_AllFakeRepositoryInputs_ConfiguresGymMembershipAndReturnsMessage()
    {
        const string name = "Sally Wong";
        const decimal amount = 35.00M;

        var sut = new GymMembershipPresenter(_gymMembershipFeeRepository,
                                    _pdfInvoiceParserRepository,
                                    _nationalGymRegistrationRepository
                                    _gymMembershipRepository,
                                    _startTransactionView);
        sut.CreateNewGymMembership(name, amount);

        Assert.AreEqual("Your membership has been processed.", _gymMembershipView.Message);
    }
}

10. The SECOND integration test will test ONLY the interaction with the COM+ object. It does this by replacing one of the fake interface implementations with a real interface implementation, in this case, ComPlusCallerGymMembershipFeeRepository class.


    [Test]
    public void Constructor_RealComPlusGymMembershipFeeAndFakeRepositoryInputs_ConfiguresGymMembershipAndReturnsMessage()
    {
        const string name = "Sally Wong";
        const decimal amount = 35.00M;

        _gymMembershipFeeRepository = new ComPlusCallerGymMembershipFeeRepository();

        var sut = new GymMembershipPresenter(_gymMembershipFeeRepository,
                                    _pdfInvoiceParserRepository,
                                    _nationalGymRegistrationRepository
                                    _gymMembershipRepository,
                                    _startTransactionView);
        sut.CreateNewGymMembership(name, amount);

        Assert.AreEqual("Your membership has been processed.", _gymMembershipView.Message);
    }

11. What goes into the class ComPlusCallerGymMembershipFeeRepository.cs? A call to the ORIGINAL logic which you worked so hard to extract out into an independent class and an independent method:


public class ComPlusCallerGymMembershipFeeRepository : IParkingLotRepository
{
    public GymMembership CreateMembershipFee(string name)
    {
        var myExtractedClass = new MyExtractedClass();
        double amountCharged = myExtractedClass.CallToLegacyComObject(name);

        var gymMembership = new GymMembership { Name = name, Amount = amountCharged };
        return gymMembership;
    }
}

From here, you can proceed to create 3 more integration tests (with 3 more real implementation classes that call the original logic in the extracted class.) Each integration test will call only one real implementation, and the rest as fakes, allowing you to independently verify the behavior of each, separate action:

against the COM+ legacy object
against the 3rd party DLL
against the web service
against the ADONET db layer.

Conclusion
So let's review: you STARTED with a button_click event handler containing long procedural code that did 4 completely distinct actions, which you could not test.

You have ENDED with 4 decoupled interfaces, each representing only one of the actions, and you have the ability to test them independently by implementing each interface, either as mocks in a unit test (to check that your presenter coordinates correctly), as fakes in an integration test (to create pretend success classes for stuff you don't currently care about) or as real implementation classes in an integration test (which actually tests a single, specific action against the original functionality of your legacy code.)

NOTE As a final step, you would implement the IGymMembershipView interface on your original ASPX page, and have the button_click event either call directly to the method GymMembershpPresenter.CreateNewGymMembership(name, amount), or via a View event's event handler implementation within the presenter. This is an important final refactoring, so that both your integration tests, and your presentation layer, would be calling the same (tested) code.

TDD Kata for DDD (building a simple domain model)

2010-07-19T21:22:00.000-07:00

Overview
1) The goal of this TDD kata is to build a simple domain model from tests.

2) The code for the kata is posted here, on github.

3) It will be based on the user story:
"A CSR (customer service rep) can manually generate monthly charges for a customer's gym membership."

4) The following classes will be created as part of the kata.
Entities:

Gym
MonthlyPackage
Customer
Batch
Transaction

Value Objects:

Address

Note how they create three (extremely small) aggregates:

5) Collection encapsulation:
Collections should be encapsulated in domain models so that the ability to change collections flows only out of test-driven scenarios. When creating your collections, use the following approach to encapsulate the collections: a private IList<T> field, and a public getter IEnumerable<T> property:


private readonly IList<MonthlyPackage> _monthlyPackages;

public Gym()
{
    _monthlyPackages = new List<MonthlyPackage>();
}

public IEnumerable<MonthlyPackage> MonthlyPackages
{
    get { return _monthlyPackages; }
}

6) Each time you are asked to create a test against a DIFFERENT entity, create a new test class, for example:

GymTests.cs to test Gym
CustomerTests.cs to test Customer

7) Since equality in a domain model is frequently based on an Id property (such as NHibernate might use to map to an underlying data store), we'll create an EntityBase class to store entity identity.

Setup
1) Create a new solution with two projects:

Tests.Unit
Domain

2) In the test project, add a reference to the NUnit.Framework.DLL.

3) Create your first test class, GymTests.cs, and add a using statement for NUnit.Framework.

TDD Kata for DDD, part 1
Part 1 is by far the longest part of the kata, but is mostly setup; creating classes, relationships and properties.

1) Create a test to verify that Gym is an instance of EntityBase

Note For each test, I'll provide a code sample. The complete kata is here, on github.

 [Test]
public void Constructor_NoInputParams_IsInstanceOfEntityBase()
{
    var sut = new Gym();
    Assert.IsInstanceOfType(typeof(EntityBase), sut);
}

2) Verify that two EntityBase instances are equal when both have the same int Id value.


[Test]
public void TwoInstances_SameIdProperty_AreEqual()
{
    const int idToAdd = 9135121;
    var sut1 = new EntityBase { Id = idToAdd };
    var sut2 = new EntityBase { Id = idToAdd };
    Assert.AreEqual(sut1, sut2);
}

3) Two EntityBase instances are not equal when each has a different Id value.


[Test]
public void TwoInstances_DifferentIdProperty_AreNotEqual()
{
    var sut1 = new EntityBase { Id = 3819025 };
    var sut2 = new EntityBase { Id = 82934 };
    Assert.AreNotEqual(sut1, sut2);
}

4) Two EntityBase instances are not equal when both have a 0 Id value.


[Test]
public void TwoInstances_ZeroIdProperty_AreNotEqual()
{
    const int idToAdd = 0;
    var sut1 = new EntityBase { Id = idToAdd };
    var sut2 = new EntityBase { Id = idToAdd };
    Assert.AreNotEqual(sut1, sut2);
}

5) MonthlyPackage is an instance of EntityBase.


[Test]
public void Constructor_NoInputParams_IsInstanceOfEntityBase()
{
    var sut = new MonthlyPackage();
    Assert.IsInstanceOfType(typeof(EntityBase), sut);
}

6) MonthlyPackage has a name and price.


[Test]
public void NameAndPriceProperties_Set_MatchAssignedValues()
{
    const string name = "Test Package";
    const decimal price = 35.00M;

    var sut = new MonthlyPackage {Id = 35, Name = name, Price = price};

    Assert.AreEqual(name, sut.Name);
    Assert.AreEqual(price, sut.Price);
}

7) Gym has MonthlyPackages collection.


[Test]
public void MonthlyPackagesProperty_Getter_HasCountOf0()
{
    var sut = new Gym();
    Assert.AreEqual(0, sut.MonthlyPackages.Count());
}

8) Adding a MonthlyPackage to Gym increments count.


[Test]
public void AddMonthlyPackageMethod_MonthlyPackageInput_IncrementsMonthlyPackagesCount(
{
    var sut = new Gym();
    Assert.AreEqual(0, sut.MonthlyPackages.Count());
    sut.AddMonthlyPackage(new MonthlyPackage());
    Assert.AreEqual(1, sut.MonthlyPackages.Count());
}

9) Adding the same MonthlyPackage throws an exception.


[Test]
[ExpectedException(typeof(ArgumentException), ExpectedMessage = "You cannot add a duplicate MonthlyPackage.")]
public void AddMonthlyPackageMethod_DuplicateInput_ThrowsException()
{
    var sut = new Gym();
    var monthlyPackage1 = new MonthlyPackage {Id = 1535235};
    sut.AddMonthlyPackage(monthlyPackage1);
    sut.AddMonthlyPackage(monthlyPackage1);
}

Note This kind of test is satisfied by putting a guard condition at the beginning of the method. Remember to use "red, green, refactor" to extract each guard condition you create into a meaningfully named static method.

10) Address MUST have a non-null Street1, City, and Province, or throw an exception.


[Test]
[ExpectedException(typeof(ArgumentException), ExpectedMessage = "You must provide a non-null address.")]
public void Constructor_StreetNullWithCityAndProvince_ThrowsException()
{
    const string street = "";
    const string city = "Winnipeg";
    const string province = "MB";

    var sut = new Address(street, city, province);

}

[Test]
[ExpectedException(typeof(ArgumentException), ExpectedMessage = "You must provide a non-null city.")]
public void Constructor_StreetWithNullCityAndProvince_ThrowsException()
{
    const string street = "1234 Happy St";
    const string city = "";
    const string province = "MB";

    var sut = new Address(street, city, province);

}

[Test]
[ExpectedException(typeof(ArgumentException), ExpectedMessage = "You must provide a non-null province.")]
public void Constructor_StreetWithCityAndNullProvince_ThrowsException()
{
    const string street = "1234 Happy St";
    const string city = "Winnipeg";
    const string province = "";

    var sut = new Address(street, city, province);

}

11) Two Addresses are the same when they have the same Street1, City and Province.


[Test]
public void TwoInstances_SameConstructorInputs_AreEqual()
{
    const string street = "1234 Happy St";
    const string city = "Winnipeg";
    const string province = "MB";

    var sut1 = new Address(street, city, province);
    var sut2 = new Address(street, city, province);
    Assert.AreEqual(sut1, sut2);
}

12) Customer is an instance of EntityBase.


[Test]
public void Constructor_NoInputParams_IsInstanceOfEntityBase()
{
    var sut = new Customer();
    Assert.IsInstanceOfType(typeof(EntityBase), sut);
}

13) Customer HAS-A Address.


[Test]
public void AddressProperty_Set_AddressEqualsCustomerAddress()
{
    const string street = "1234 Happy St";
    const string city = "Winnipeg";
    const string province = "MB";

    var address = new Address(street, city, province);

    var sut = new Customer {Address = address};

    Assert.AreEqual(address, sut.Address);
}

14) Customer HAS-A MonthlyPackage.


[Test]
public void MonthlyPackageProperty_Set_PackageEqualsCustomerMonthlyPackage()
{
    var monthlyPackage = new MonthlyPackage { Id = 91351 };

    var sut = new Customer {MonthlyPackage = monthlyPackage};

    Assert.AreEqual(monthlyPackage, sut.MonthlyPackage);
}

15) Batch is an instance of EntityBase.


[Test]
public void Constructor_NoInputParams_IsInstanceOfEntityBase()
{
    var sut = new Batch();
    Assert.IsInstanceOfType(typeof(EntityBase), sut);
}

16) Transaction is an instance of EntityBase.


[Test]
public void Constructor_NoInputParams_IsInstanceOfEntityBase()
{
    var sut = new Transaction();
    Assert.IsInstanceOfType(typeof(EntityBase), sut);
}

17) Batch has Transactions.


[Test]
public void TransactionProperty_Getter_HasCountOf0()
{
    var sut = new Batch();
    Assert.AreEqual(0, sut.Transactions.Count());
}

18) Adding a Transaction to Batch increments Count.


[Test]
public void AddTransactionMethod_TransactionInput_IncrementsCount()
{
    var sut = new Batch();
    Assert.AreEqual(0, sut.Transactions.Count());
    sut.AddTransaction(new Transaction {Id = 91352, Amount = 10.01M});
    Assert.AreEqual(1, sut.Transactions.Count());
}

19) Adding the same Transaction to batch throws an Exception.


[Test]
[ExpectedException(typeof(ArgumentException), ExpectedMessage = "You cannot add duplicate transactions.")]
public void AddTransactionMethod_DuplicateInput_ThrowsException()
{
    var transaction = new Transaction { Id = 91325125, Amount = 10.01M };

    var sut = new Batch();
    sut.AddTransaction(transaction);
    sut.AddTransaction(transaction);
}

20) Adding Transaction with Amount < $10 throws an Exception.


[Test]
[ExpectedException(typeof(ArgumentException), ExpectedMessage = "A transaction charge must be at least $10.")]
public void AddTransactionMethod_AmountLessThanTenDollars_ThrowsException()
{
    var transaction = new Transaction { Id = 91325125, Amount = 9.99M };

    var sut = new Batch();
    sut.AddTransaction(transaction);
}

TDD Kata for DDD, part 2
Part 2 relies on everything you have created in the first part to create tests which exercise the user story. Once you have completed the kata, you could create additional user stories, and build tests based on the entities you have already established.

21) Customer can manually generate monthly charge with the Customer.BillForMonthlyCharge(DateTime input) method:
a) Customer creates a Batch and adds a Transaction to it, assigning package price to Transaction's NetAmount.
b) after running a new Batch and Transaction record have been created with Transaction.Amount = Customer.MonthlyPackage.Price.


[Test]
public void BillForMonthlyChargeMethod_CustomerPackageInput_GeneratesBatchWithTransaction()
{
    const decimal price = 12.20M;
    var monthlyPackage = new MonthlyPackage { Id = 1235, Name = "Top Fit", Price = price };
    var sut = new Customer { Id = 91352, MonthlyPackage = monthlyPackage };
    var batch = sut.BillForMonthlyCharge(DateTime.Today);
    Assert.IsTrue(batch.TransactionsContainsChargeOf(price));
}

22) Adding a manual charge for a Customer from Ontario throws an exception.


[Test]
[ExpectedException(typeof(Exception), ExpectedMessage = "A manual charge cannot be run for Ontario customers.")
public void BillForMonthlyChargeMethod_CustomerIsFromOntario_ThrowsException()
{
var monthlyPackage = new MonthlyPackage { Id = 1235, Name = "Top Fit", Price = 9.20M };
var address = new Address("1234 Happy St", "Toronto", "Ontario");
var sut = new Customer { Id = 91352, MonthlyPackage = monthlyPackage, Address = address };
sut.BillForMonthlyCharge(DateTime.Today);
}

This completes the TDD kata. However, you can see that this is an obvious jumping off point for writing additional user stories and writing tests to take the domain model further. Try writing at least 2 additional user stories and implementing them as tests.

[end]

TDD Kata for decoupling a finicky 3rd party class with Dependency Injection and Mocks

2010-07-06T23:10:00.000-07:00

For a developer who is new to the concept of Dependency Injection, it can be difficult to see the motivation past the theory. A way to make this practical for the developer is to focus on PAIN POINTS.

One pain point which developers are increasingly encountering is the use of 3rd party DLLs for special functions (eg. for image processing or PDF manipulation), where those DLLs employ strict (finicky) licensing requirements. A typical scenario would be one license for the production server, but a limited or temporary-only license for the development box (or boxes). If a developer has coupled their code by instantiating a third party class directly within their own custom class, they may find themselves at a current or future point unable to run the code on their development machine due to a finicky, frustrating, licensing exception.

This is a very practical case for the need to decouple their code. When the developer starts to backfill legacy code like this with TDD-based unit tests, this is an opportunity for them to employ DI (dependency injection) and a mocking framework. After their test initially fails with the finicky licensing error, they can update the SUT (their custom class, the "system-under-test") to interact with an abstraction (the interface) rather than directly with the problematic third party class. They can use a mocking framework to substitute a mock implementation that will satisfy the requirements of the call to the 3rd party class.

This concept can be practiced with a TDD kata that specifically walks through the steps to achieve this. The rest of this blog post demonstrates that kata.

NOTE The code demonstrating a completed form of this kata can be found here on github.

The following TDD kata demonstrates how to decouple a custom class that calls to a finicky 3rd party class, using Dependency Injection and mocks.

Setup
1) Create a solution with two projects:

Tests.Unit
Utils

2) Add references to NUnit and Rhino.Mocks to your Tests.Unit project.
3) This is a decoupling scenario, so you want to begin with coupled code. Therefore, create a class, FinickyThirdPartyApp with a method that throws an exception (eg. that its licensing is broken for dev machines)


public class FinickyThirdPartyApp
{
    public string DoSomethingProprietary()
    {
        throw new Exception("I'm FINICKY about licensing on dev machines! You can't use me, dev!");
    }
}

4) Now create a custom class with a single method that instantiates the third party class, and calls its proprietary method.


public class FinickyCoordinator
{
    public string DoMyCustomAction()
    {
        var finickyThirdPartyApp = new FinickyThirdPartyApp();
        return finickyThirdPartyApp.DoSomethingProprietary();
    }
}

5) You are now ready to begin.

The Kata
1) In the Tests.Unit namespace, create a class, FinickyCoordinatorTests.cs.
2) Create a test that calls DoMyCustomAction() method and asserts an expected value for the string.
3) Run the test. It will fail with the licensing exception from the third party app.
4) Now add Rhino.Mocks to the test class. Create property [Setup] and [TearDown] methods, and mock a new interface, IFinickyWrapper.


[TestFixture]
public class FinickyCoordinatorTests
{
    private MockRepository _mockRepository;
    private IFinickyWrapper _finickyWrapper;

    [SetUp]
    public void SetUp()
    {
        _mockRepository = new MockRepository();
        _finickyWrapper = _mockRepository.StrictMock<IFinickyWrapper>();
    }

    [TearDown]
    public void TearDown()
    {
        _mockRepository.VerifyAll();
    }

    // test here
}

5) In the test, change the constructor of your custom class (in this sample code, FinickyCoordinator) to accept IFinickyWrapper as an input parameter (the dependency-injected interface).


var sut = new FinickyCoordinator(_finickyWrapper);
var result = sut.DoMyCustomAction();

result.ShouldEqual(someValue);

6) Finally, begin the test by specifying the mock expectations (the call to the interface wrapper method, and the expected returned string).


[Test]
public void DoMyCustomActionMethod_NoInputParams_ReturnsExpectedString()
{
    const string someValue = "Some value returned";
    Expect.Call(_finickyWrapper.DoSomethingProprietary()).Return(someValue);

    _mockRepository.ReplayAll();

    var sut = new FinickyCoordinator(_finickyWrapper);
    var result = sut.DoMyCustomAction();

    result.ShouldEqual(someValue);
}

7) Run the test, which will fail.
8) Now correct the code within FinickyCoordinator to match the dependency injection.


public class FinickyCoordinator
{
    private readonly IFinickyWrapper _finickyWrapper;

    public FinickyCoordinator(IFinickyWrapper finickyWrapper)
    {
        _finickyWrapper = finickyWrapper;
    }

    public string DoMyCustomAction()
    {
        return _finickyWrapper.DoSomethingProprietary();
    }
}

9) Run the test, and verify that the test is passing.
10) Finally, create an implementation class which actually calls to the 3rd party class (but will no longer be called by the unit test.

)
public class ThirdPartyFinickyWrapper : IFinickyWrapper
{
    public string DoSomethingProprietary()
    {
        var finickyThirdPartyApp = new FinickyThirdPartyApp();
        return finickyThirdPartyApp.DoSomethingProprietary();
    }
}

The kata is complete.

Quick Find Algorithm (from Sedgewick) in C# using TDD

2010-07-03T12:02:00.000-07:00

In "Algorithms in Java", by Robert Sedgewick, available on Amazon.com here, chapter 1 explores a connectivity algorithm in increasingly complex iterations.

The goal of the connectivity process is as follows:

be able to add pairs of connections as integers (2-3, 5-1, 8-7).
The connections are transitive, so adding 2-3, 3-5, and 5-7 menas that 2-7 is also connected.
Once a transitive connection exists, adding the direct connection (2-7) is redundant and therefore ignored.

MY goal in working through these algorithms is to use Test-Driven Development in C# to solve and evolve them.

Starting from the initial description of the connectivity process, I created a series of tests against a utility class that added connectivity pairs. Each time, before adding them, the utility class checks to see whether a transitive connection can be established across the already existing pairs in an in-memory array. This worked, and all tests were passing (for a very simple case.)

However, in reading further, I found that Sedgewick points out that while this is the typical first approach taken, it has significant problems:

"First, the number of pairs might be sufficiently large to preclude our saving them all in memory
in practical applications. Second, and more to the point, no simple method immediately suggests itself for determining whether two objects are connected from the set of all the connections, even if we could save them all!"

(The book is excellent and I recommend reading it directly to get the full account.)

From here, Sedgewick works through a series of iterative algorithms, each coming closer to the complete solutions.This approach dovetails nicely with the principle in Test-Driven Development of:

"Start by building the simplest thing that could possibly work."

For example, in the TDD Calculator kata, this might mean that you solve your first test by returning 0 (hard-coded) when an empty string is passed.

In the case of this connectivity algorithm, first pass, the Quick find approach is the simplest thing that could possibly work:

For each pair you add, (for exampe: 4-9) OVERWRITE the value on one side to be the same value as the other side.

For example, if you started with an array like this:


new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };

By the time you were done (all connections established), where the last input pair were, let's say, 7-1, the array would look like this:


new int[] { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 };

Does this solve every connectivity issue? No. But neither does returning 0 in Calculator kata; it is simply the
first, simplest thing that works.

Having read Sedgewick's explanation for Quick Find, I decided to start by building the Quick Find algorithm as a series of unit tests. As you read through the unit tests in order (here on github), they document the progression through variations until all Quick Find connectivity add requirements are satisfied.

In the QuickFinder class itself, I would normally refactor without preserving previous iterations. However, for
documentation purposes, to trace the steps that got us here, I have kept (commented out) the previous iterations.

NOTE To see how the tests failed/evolved across versions, try uncommenting an earlier iteration.

As I proceed further into Ch.1 of Sedgewick, additional iterations of the algorithms will be introduced. Time-permitting, my goal is to created each of these algorithms using TDD as well, and post them to github.

All kinds of Repository implementations

2010-06-24T22:51:00.000-07:00

I've been looking back and reviewing the approaches on some of my previous projects. In particular, I've been going back to review a project I did in 2005. At that point, I didn't really have the concepts of domain model and repository clear: for data access I was using POJOs, but loading them internally, within each POJO, via a private method (which called to stored procedures with parameters using SqlDataReader.)

In all projects since, I've used a Domain Model and Repository, typically with NHibernate for the ORM mapping/queries.

As I started using Rhino Mocks, I also created mock repositories for MVC and MVP unit testing. And I also have created fake repositories (returning collections of dummy objects), and LinqToSql repositories as part of the PRO ASP.NET MVC book examples [Sanderson].

The only combination I hadn't done was original ADO.NET/SqlDataReader in a repository.

In the following code sample, I add an ADO.NET repository to an Model-View-Presenter scenario (which originally had only mocked repository and view interfaces against a Presenter). To make a complete integration test:

1) I create a view interface implementation (WinForm) where the List<Project> setter property assigned its value to a simple data grid
2) I create an AdoNetProjectsRepository implementation class where List<Project> FindAllProjects() method returns a list of Projects from the database.

Integration test with Form1.cs and ADO.NET Repository


[TestFixture]
public class ProjectsPresenterIntegrationTests
{
    [Test]
    public void ShowProjectsEvent_Raised_RetrievesProjectsFromRepositoryAndAssignedToViewProjectsDisplay()
    {
        IProjectsRepository adoNetProjectsRepository = new AdoNetProjectsRepository();
        var projects = adoNetProjectsRepository.FindAllProjects();

        IProjectsView projectsView = new Form1();
        projectsView.ProjectsDisplay.ShouldEqual(projects);
    }
}

IProjectsView implementation as WinForm


public Form1()
{
    InitializeComponent();
    IProjectsRepository adoNetProjectsRepository = new AdoNetProjectsRepository();
    var projectsPresenter = new ProjectsPresenter(adoNetProjectsRepository, this);
    ShowProjects(this, EventArgs.Empty);
}

public event EventHandler ShowProjects;

public List<Project> ProjectsDisplay
{
    get
    {
        return (List<Project>)dgrProjects.DataSource;
    }
    set
    {
        dgrProjects.DataSource = value;
    }
}

Projects Presenter


public class ProjectsPresenter
{
    private readonly IProjectsRepository _projectsRepository;
    private readonly IProjectsView _projectsView;

    public ProjectsPresenter(IProjectsRepository projectsRepository, IProjectsView projectsView)
    {
        _projectsRepository = projectsRepository;
        _projectsView = projectsView;
        _projectsView.ShowProjects += new EventHandler(ProjectsViewShowProjects);
    }

    private void ProjectsViewShowProjects(object sender, EventArgs e)
    {
        _projectsView.ProjectsDisplay = _projectsRepository.FindAllProjects();
    }
}

ADO.NET Repository


public class AdoNetProjectsRepository : IProjectsRepository
{
    public List<Project> FindAllProjects()
    {
        var projects = new List<Project>();

        PopulateProjectsWithSqlDataReader(projects);

        return projects;
    }

    private static void PopulateProjectsWithSqlDataReader(ICollection<Project> projects)
    {
        SqlDataReader sqlDataReader = null;

        try
        {
            var sqlConnection = new SqlConnection(DBManager.DBConnection);
            var sqlCommand = sqlConnection.CreateCommand();

            sqlCommand.CommandText = DBManager.DBOwner + "sp_getCurrentProjects";
            sqlCommand.CommandType = CommandType.StoredProcedure;

            sqlConnection.Open();
            sqlDataReader = sqlCommand.ExecuteReader(CommandBehavior.CloseConnection);

            if (sqlDataReader == null) return;

            while (sqlDataReader.Read())
            {
                var myProject = new Project
                {
                    ProjectId = Convert.ToInt32(sqlDataReader["ProjectID"]),
                    Name = sqlDataReader["Name"].ToString(),
                    ProductName = sqlDataReader["ProductName"].ToString()
                };

                projects.Add(myProject);
            }
        }
        finally
        {
            if (sqlDataReader != null) sqlDataReader.Close();
        }
    }
}

The conclusion I drew from this experiment: while I am accustomed to (and may prefer) to use an ORM tool like NHibernate to do my query retrievals in a repository, it is by no means my only option. Even plain old ADO.NET SqlDataReader can do the trick.

The primary goal is not which data access implementation to use, but instead the abstraction of the Domain Model, Repository, and application services (controller/presenter/web service).

A brief overview of Ncqrs

2010-06-18T17:23:00.000-07:00

What is CQRS / Ncqrs?
CQRS is an evolutionary step in Domain-Driven Design (DDD). Ncqrs is an open-source implementation for.NET.

Links: CQRS
Wikipedia's entry for Command-query separation.
Udi Dahan's explanation of Command-Query Responsibility Segregation.
Greg Young's video presentation CQRS and Event Sourcing - the Business Perspective.

Links: Ncqrs
For information on Ncqrs, see ncqrs.org.
To try out the Ncqrs walkthrough tutorial, go here.

The goal of this blog post is to compare Ncqrs with regular Domain-Driven Design (particularly when used with Remote Facade), and to examine and understand the processes described in the Ncqrs tutorial.

In regular Domain-Driven Design across a web service boundary, both inputs (commands) and outputs (queries) share the same RemoteFacade and Application Service Layer, as shown in Fig. 1.

Fig.1 Regular DDD with Remote Facade

CQRS
In Command-Query Responsibility Segregation Pattern, inputs (commands) and outputs (queries) are separated and treated very differently. As Greg Young points out in the video presentation (above), using the RemoteFacade/DDD architecture for simple queries leads to an immense amount of busy work (mapping from the domain to DTOs, etc), when the real purpose of the domain model is to implement behavior/business logic--which only occurs based on input (commands).

Therefore:
CQRS in 50 words or less
1) Keep DDD and the domain model, but call it only from commands.
2) Add a new feature: TRACK each command as event history
3) For queries, SKIP the domain model. Do queries quick, dirty and denormalized.

How does Ncqrs implement this approach? Let's walk through the journey that a command follows, based on their tutorial. I've created the following diagram as a guide:

In your backend behind the RemoteFacade, create a custom command class such as PostNewTweetCommand (which inherits from Ncqrs.Commanding.CommandBase).
For any input values you wish to pass to the domain model, create properties in the custom command class. For example:
public string Message { get; set; } public string Who { get; set; }
In your WCF web service, create a method which accepts PostNewTweetCommand as input parameter.
In your client, create the WCF proxy.
In your client, create an action which instantiates PostNewTweetCommand, sets its property values, and passes it to the web service method.
In your WCF web service method, get an ICommandService instance (from Ncqrs.Commanding.ServiceModel) and use it to execute the incoming PostNewTweetCommand input parameter.
Create a PostNewTweetCommandExecutor class (which inherits from CommandExecutorBase<PostNewTweetCommand>) that--by convention--listens for executed instances of PostNewTweetCommand
Have the command executor execute the incoming command, in the context of an IUnitOfWork, against a domain model class (typically an aggregate root)
In the domain model class (eg. Tweet.cs), every public action (such as instantiation, or a method call) creates a domain event to process the incoming command, map over its input values, and then call ApplyEvent().
In this case, the contextual IUnitOfWork writes the event (TweetPostedEvent) to the event store.
As part of setting up the WCF service, three services have been bootstrapped in service of CQRS goals:
- ICommandService - already mentioned, this processes the incoming commands, and uses convention to call the correct command executor
- IEventStore - this processes each event transaction and writes it out to a separate data store (in the tutorial example, a SQL Server database)
- IEventBus - listens for new events, and for each one, makes a call out to the final piece of the ncqrs puzzle (described next)
The event bus alerts classes (again, by convention) which inherit from IDenormalizer where T is the particular event that has been saved.
The implementing class (in this case, TweetIndexItemDenormalizer is so named based on a new, separate database whose purpose is to store, simple, denormalized, read data.
The TweetIndexItemDenormalizer class implements a Handle method, which takes the TweetPostedEvent as input param, and write the values stored in that event to the denormalized data table.
Finally, the client can now (very simply) access data from this denormalized table (eg. as a simple Linq to SQL call to get a list of matching values.)

TDD kata for building Strategy Pattern in a domain model

2010-05-13T19:00:00.000-07:00

TDD katas which use a Calculator or some kind of algorithmic test are valuable for learning red/green/refactor, design-by-test, use of Resharper, keyboard shortcuts, and speed. However, I also like working with katas that:

address a new technology (eg. Win Phone 7)
test mocking (eg. M-V-P presenter tests or MVC controller tests)
design a series of classes in a domain (eg. 5-day TDD kata)

In this case, I wanted to build a kata that specifically addresses the Strategy pattern within a domain model, and how to build it intuitively using design-by-test.

NOTE The code for this kata is available here on github.

Without Strategy pattern (and more generally, without refactoring to maximum granularity), domain entities tend to grow fat, full of algorithmic business logic which they would be better to call as multiple domain service classes than to possess internally.

In this kata, the Treatment entity represents a treatment for a pet at the veterinarians' office, such as prescription, hydration, dietary advice, referral, etc. The type of treatment is implemented as a TreatmentType property member off of the Treatment class.

In a typical Strategy Pattern before-and-after scenario, the TreatmentType property would originally have encapsulated a switch statement, with different treatment type logic for each case, creating a fat entity.

NOTE A switch statement in itself is not bad; the point is that it should primarily be used for a very "thin" activity: generating the subclasses of the Strategy hierarchy.

In this TDD kata, we skip the before scenario and instead design directly to the working scenario, where we build the treatment types outside of the Treatment entity in the form of Strategy hierarchy. Upon completion, it should look something like this:

NOTE This kata will test a bit more than just Strategy. For entity classes in the above domain model (Pet and Treatment), we will also test for identity/equality by creating a base class (DomainEntity) which will handle these concerns. While entity identity is not central to Strategy, it's fundamental to the domain. So let's begin.

TDD Kata for Strategy
1) Create a Visual Studio solution with two projects/assemblies:
* Kata.Domain
* Kata.Tests.Unit (add the appropriate references to this project for the testing framework you prefer)

2) In Kata.Tests.Unit, create a test class, DomainEntityTests, and write a test for each of the following:
a) that 2 instances of DomainEntity whose Id property is the same are equal


[Test]
public void TwoInstances_SameIdPropertySet_AreEqual()
{
    const int commonId = 32753;
    var sut1 = new DomainEntity {Id = commonId};
    var sut2 = new DomainEntity {Id = commonId};

    sut1.ShouldEqual(sut2);
}

b) that 2 instances of DomainEntity whose Id property is different are not equal


[Test]
public void TwoInstances_DifferentIdPropertySet_AreNotEqual()
{
    var sut1 = new DomainEntity { Id = 4275 };
    var sut2 = new DomainEntity { Id = 3214 };

    sut1.ShouldNotEqual(sut2);
}

3) Create a test class, PetTests, which tests the following:
a) that Pet is an instance of DomainEntity


[Test]
public void Constructor_NoInputParams_IsInstanceOfDomainEntity()
{
    var sut = new Pet();
    sut.ShouldBeInstanceOf<DomainEntity>();
}

b) that Pet.Treatments association has 0 rows at first.


[Test]
public void TreatmentsProperty_Get_HasCountOf0Initially()
{
    var sut = new Pet();
    sut.Treatments.Count.ShouldEqual(0);
}

c) that Pet.AddTreatment(treatment) increments the count by 1


[Test]
public void AddTreatmentMethod_PetInputParam_IncremantsTreatmentsCount()
{
    var sut = new Pet();
    sut.Treatments.Count.ShouldEqual(0);
    sut.AddTreatment(new Treatment());
    sut.Treatments.Count.ShouldEqual(1);
}

4) Create a test class, TreatmentTests, which tests the following:
a) that Treatment is an instance of DomainEntity.


[Test]
public void Constructor_NoInputParams_IsInstanceOfDomainEntity()
{
    var sut = new Treatment();
    sut.ShouldBeInstanceOf<DomainEntity>();
}

We'll come back to add additional tests later.

5) Create a test class, TreatmentTypeTests, which tests the following:
a) that TreatmentType has no public constructors (use LINQ)


[Test]
public void Constructors_Public_ShouldBeNone()
{
typeof(TreatmentType).GetConstructors()
.Where(constructorInfo => constructorInfo.IsPublic).Count().ShouldEqual(0);
}

NOTE This is because the base class of a Strategy hierarchy must use a creation method to control class instantiation, to only create subclasses of the base class.
b) that the CreateTreatmentType creation method accepts a TreatmentTypeEnum enumeration, and returns an instance of the subclass specified by name in the enumeration. (For the first test, use Surgery).


[Test]
public void CreationMethod_SurgeryTreatmentEnumInput_ReturnsInstanceOfSurgery()
{
    var surgeryTreatment = TreatmentType.CreateTreatment(Treatment.TreatmentEnum.Surgery);
    surgeryTreatment.ShouldBeInstanceOf<Surgery>();
    surgeryTreatment.ShouldBeInstanceOf<TreatmentType>();
}

c) recreate this test identically for every subclass type, including:

Dietary
Hydration
Prescription
Referral
Surgery

When you are done, the creation method of the TreatmentType Strategy base class should look like this:


public static TreatmentType CreateTreatment(Treatment.TreatmentEnum treatmentEnum)
{
    switch(treatmentEnum)
    {
        case Treatment.TreatmentEnum.Dietary:
            return new Dietary();
            break;
        case Treatment.TreatmentEnum.Hydration:
            return new Hydration();
            break;
        case Treatment.TreatmentEnum.Prescription:
            return new Prescription();
            break;
        case Treatment.TreatmentEnum.Referral:
            return new Referral();
            break;
        case Treatment.TreatmentEnum.Surgery:
            return new Surgery();
            break;
    }
    return null;
}

6) Now we come to the CourseOfAction property, which is the first property of the TreatmentType base class, and which is about to bring the Strategy hierarchy into full bloom. The default test will simply assert a value of CourseOfAction on the base class. Therefore:
a) Test that a new property of TreamentType, string::CourseOfAction returns a string that says "do something".


[Test]
public void CourseOfActionProperty_SurgeryTreamentEnumInput_ReturnsSurgeryCourseOfAction()
{
    var sut = TreatmentType.CreateTreatment(Treatment.TreatmentEnum.Surgery);
    sut.CourseOfAction.ShouldEqual("Do something.");
}

7) Having a single value in the base class, "Do something", is kind of pointless, other than to introduce the property concept. What we really want is polymorphic differentiation for this property, where the output varies for each subclass. To do this, first modify the CourseOfAction property to be abstract:


public abstract string CourseOfAction { get; }

This immediately has two impacts:
a) the compiler forces you to "correct" the class, making it abstract as well.


public abstract class TreatmentType
{
     ...
}

a) the compiler generates errors, telling you that the abstract property must be implemented in each subclass. This is perfect, as it completes the Strategy. Correct this now:


[Test]
public void CourseOfActionProperty_DietaryTreamentEnumInput_ReturnsDietaryCourseOfAction()
{
var sut = TreatmentType.CreateTreatment(Treatment.TreatmentEnum.Dietary);
sut.CourseOfAction.ShouldEqual("Give dietary advice.");
}

[Test]
public void CourseOfActionProperty_HydrationTreamentEnumInput_ReturnsHydrationCourseOfAction()
{
var sut = TreatmentType.CreateTreatment(Treatment.TreatmentEnum.Hydration);
sut.CourseOfAction.ShouldEqual("Hydrate the pet.");
}
...etc...

8) Finally, we are ready to link TreatmentType up to Treatment. We will fully encapsulate the Strategy pattern by assigning the TreatmentEnum in the constructor of Treatment. The TreatmentType property will then simply return the correct subclass and subclass property values.
a) Therefore, test that treatment.TreatmentType.CourseOfAction property results from a simple chain, given that the constructor is assigned a TreatmentEnum param.


[Test]
public void Constructor_TreatmentEnumParam_ReturnsCorrectCourseOfActionProperty()
{
    var sut = new Treatment(Treatment.TreatmentEnum.Dietary);
    sut.TreatmentType.CourseOfAction.ShouldEqual("Give dietary advice.");
}

9) Note that changing the Treatment entity constructor will break a few places in your code. Fix each one by assigning an enum to the constructor.

Congratulations! You have now implemented the complete Strategy Pattern as a domain service, completely encapsulated by Treatment. If you wish to compare your code, have a look at the implementation here, on github.

How to write unit tests for your FluentNHibernate class maps

2010-05-01T16:30:00.000-07:00

I've been building a spike to learn FluentNHibernate, with the constraint that each step I take, I start with a test. Since FluentNHibernate uses code rather than XML to specify the class mapping (using ClassMap), one of my goals has been to figure out how to test these code-based mappings.

The FluentNHibernate (source on github) includes extensive unit tests, one of which, PersistenceSpecificationTester, performs detailed tests using PersistenceSpecification<T> to validate class maps.

For the spike, I've tried to simplify this down as much as possible, working with a single entity, a base class (DomainEntity, to handle equality) and a static utility method for building an ISessionSource containing any entity class.

Use the following to build your class mapping test:

1) Create a domain model with two entities:

Product
DomainEntity, a common base class for handling identity/equality

Product.cs


public class Product : DomainEntity
{
    // Location is an immutable value object containing Aisle and Shelf properties;
    // included to demonstrate FluentNHibernate's mapping of an entity component
    public Location Location { get; set; } 
    public decimal Price { get; set; }
    public string Name { get; set; }
}

DomainEntity.cs


public class DomainEntity
{
    public int Id { get; set; }

    public override bool Equals(object obj)
    {
        var other = obj as DomainEntity;

        return other != null 
            && other.Id > 0
            && other.Id.Equals(this.Id);
    }

    public override int GetHashCode()
    {
        return this.Id.GetHashCode();
    }
}

2) Create a mapping file using FluentNHibernate's ClassMap<T>.

ProductMap.cs


public class ProductMap : ClassMap<Product>
{
    public ProductMap()
    {
        Id(x => x.Id);
        Map(x => x.Name);
        Map(x => x.Price);

        Component(x => x.Location, m =>
        {
            m.Map(x => x.Aisle);
            m.Map(x => x.Shelf);
        });
    }
}

3) Create a static class/method that accepts any domain entity class (i.e. which extends DomainEntity) and returns a mock in-memory NHibernate session containing an instance of the entity (which we will use next to test the mappings).

FluentNHibernateMappingTester.cs


using FluentNHibernate;
using Gaddzeit.Spike.Domain.Entities;
using NHibernate;
using Rhino.Mocks;

namespace Gaddzeit.Spike.Tests.Unit
{
    public static class FluentNHibernateMappingTester
    {
        public static ISessionSource GetNHibernateSessionWithWrappedEntity<T>(T tMappedEntityWithinSession) where T : DomainEntity
        {
            var transaction = MockRepository.GenerateStub();
            var session = MockRepository.GenerateStub();
            session.Stub(s => s.BeginTransaction()).Return(transaction);
            session.Stub(s => s.Get<T>(null)).IgnoreArguments().Return(tMappedEntityWithinSession);
            session.Stub(s => s.GetIdentifier(tMappedEntityWithinSession)).Return(tMappedEntityWithinSession.Id);

            var sessionSource = MockRepository.GenerateStub();
            sessionSource.Stub(ss => ss.CreateSession()).Return(session);
            return sessionSource;
        }
    }
}

4. To test the entity mapping, you need a comparer class that implements IEqualityComparer, and can test both the equality of the entity itself, as well as the equality of any of its properties.

ProductComparer.cs


public class ProductComparer : IEqualityComparer
{
    public bool Equals(object x, object y)
    {
        if (x is Product && y is Product)
            return ((Product)x).Id == ((Product)y).Id;
        if (x is string && y is string)
            return x.ToString().Equals(y.ToString());
        if (x is decimal && y is decimal)
            return Convert.ToDecimal(x).Equals(Convert.ToDecimal(y));
        throw new EqualityComparerUnhandledComparisonException();
    }

    public int GetHashCode(object obj)
    {
        if (obj is Product) 
            return ((Product) obj).GetHashCode();
        if (obj is string) 
            return obj.ToString().GetHashCode();
        if (obj is decimal)
            return Convert.ToDecimal(obj).GetHashCode();
        throw new EqualityComparerUnhandledComparisonException();
    }
}

5. Finally: create a test for the mapping of Product, which calls to the static method to setup the Product instance in the mocked in-memory NHibernate Session (returned as ISessionSource), and then passes ISessionSource and the above ProductMapper into PersistenceSpecification in order to perform validation on any mapping specified. In the test below, we test only one of the property mappings, Product.Name by calling the PersistenceSpecification.CheckProperty() method.

ProductMappingTests.cs


using FluentNHibernate.Testing;
using Gaddzeit.Spike.Domain.DomainServices;
using Gaddzeit.Spike.Domain.Entities;
using NUnit.Framework;

namespace Gaddzeit.Spike.Tests.Unit
{
    [TestFixture]
    public class ProductMappingTests
    {
        [Test]
        public void NameProperty_IsMapped_Correctly()
        {
            var product = new Product
            {
                Id = 35,
                Location = new Location(35, 27),
                Name = "Hammer",
                Price = 35.99M
            };

            var identicalProduct = new Product
            {
                Id = 35,
                Location = new Location(35, 27),
                Name = "Hammer",
                Price = 35.99M
            };
            var sessionSource = FluentNHibernateMappingTester.GetNHibernateSessionWithWrappedEntity(identicalProduct);
            var spec = new PersistenceSpecification(sessionSource, new ProductComparer());
            spec.CheckProperty(p => p.Name, product.Name).VerifyTheMappings();
        }

    }
}

That's it! Your test should pass, and you have verified that your entity is mapped correctly, without setting up a real connection to a database.

Simple WCF service for Win Phone 7 / Silverlight testing

2010-04-16T13:02:00.000-07:00

This blog post is meant to briefly illustrate a simple WCF client configuration which returns a CustomerDTO, which you can call and try out from your Win Phone 7, Silverlight, or other client.

The client calls to a simple WCF service on my website, gaddzeit.com, that returns a list of (random-name-generated) customers. The number of rows returned is based on the parameter int howMany (eg. 50 returns 50 CustomerDTO rows). There is a upper limit of 1000 rows returned before a warning exception is thrown.

Do the following:

Create a client app (a unit test library, console app, a repository, etc.)
Right-click the project and select "Add A Service Reference..."
enter the WCF service URL shown below
click the Go button
once the service is loaded, provide a meaningful name for the namespace (eg. FakeCustomerService)


http://www.gaddzeit.com/FakeCustomerService/

Open the config file (ServiceReferences.ClientConfig | web.config | app.config). The <system.serviceModel> element will have been generated for the WCF service:


<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IGaddzeitServices" maxBufferSize="2147483647"
                    maxReceivedMessageSize="2147483647">
                    <security mode="None" />
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://www.gaddzeit.com/FakeCustomerService/FCService.svc"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IGaddzeitServices"
                contract="GaddzeitServices.IGaddzeitServices" name="BasicHttpBinding_IGaddzeitServices" />
        </client>
    </system.serviceModel>
</configuration>

Next, enter a using statement for the web service namespace into:

the Repository or Command class (if using MVVM)
the code-behind (if responding directly from a control event handler in the presentation layer)

Finally, enter the following code into the above class. This code instantiates the web service, and attaches the GetRandomCustomerNamesCompleted (asynchronous) event to a callback method.
NOTE Win Phone 7 (and Silverlight) require asynchronous web service calls.


const int howManyCustomersToReturn = 40;
GaddzeitServicesClient webService = new GaddzeitServicesClient();
webService.GetRandomCustomerNamesAsync(howManyCustomersToReturn);
webService.GetRandomCustomerNamesCompleted += new EventHandler(webService_GetRandomCustomerNamesCompleted);

Below is a rough sample of the callback method (in this sample, I am concatenating the customer names to an instance string _customerNames.)


void webService_GetRandomCustomerNamesCompleted(object sender, GetRandomCustomerNamesCompletedEventArgs e)
{
   var customers = new List<CustomerDTO>(e.Result);
    foreach (var customer in customers)
    {
        if (customer == null)
        {
            continue;
        }
        _customerNames += string.Format("{0} {1}\r\n", customer.FirstName, customer.LastName);
    }
}

NOTE You could also add code to track the time on the response by comparing DateTime.Now.Ticks for before and after the web service call.

NOTE If you want to build a complete Win Phone 7 client using TDD, mocks and MVVM, this earlier blog post provides a walk through. In this blog post, the only piece NOT included is a WCF client call (the walkthrough places a comment recommending a WCF client call inside the CustomerRepository.Save() method.)

Three types of services in Domain-Driven Design

2010-04-12T09:10:00.000-07:00

I've been re-reading Domain-Driven Design [Evans]. My first reading was in 2006 when I'd just started using Hibernate/NHibernate. In the years since then I've done several projects using a domain, a repository, and tests to validate the domain.

In re-reading the book, I'm seeing that Evans spoke about 3 types of classes in the domain:

Entites
Value Objects
[Domain] Services

In the projects I had done, I used only the first of these, Entities:

Every class had a PK-mapped identity from the db.
I had not used the Value Object abstraction to group attributes using composition (eg. Person.Address).
My use of services had been limited to services outside the domain (application and infrastructure, defined below.) As a consequence, I had observed a design issue in my domain entities: even though though they had thorough test coverage, the entities had become large, with many methods. As a result, the tests that ran against these entities by definition had to be coarse grained, often testing logic nested several levels deep within the entity..

Last fall, I revisited the book Refactoring [Fowler], and recognized that the use of delegation (Extract Class, Strategy, and others) would help to move a lot of the logic out of my entity classes into abstractions devoted to particular parts of the business logic. Among many benefits of this, tests could now be written directly against these abstractions. However, my concern was WHERE these extracted non-entity classes should go. Would they clutter up the domain? Should I create a separate namespace specifically for these classes?

With this question in the back of my mind, Evans explanation of Domain Service classes made perfect sense. They belong inside the domain and serve the entities as useful abstractions in their own right. And they are not to be confused with either:

Application services (eg. the controller in MVC, or a web method); or
Infrastructure services (eg. adapters on calls to external infrastructure outside the application.)

The following graphic is my attempt to crystallize my understanding of the 3 distinct types of services for future reference. I've highlighted the different services in each layer.

Short form: TDD Kata for MVVM on Windows Phone 7

2010-03-28T23:36:00.000-07:00

Can you complete the kata in under 60 minutes?

* What is a TDD kata? See the Calculator kata
* This is the text-only version. If you're trying this for the first time, work through the detailed version with code snippets.

BEFORE YOU START (SETUP)
a) Install VS 2010 Express for Win Phone 10, and add the unit testing components. [Details].
b) Create a Windows Phone 7 application (a single project, single solution--required by the unit testing framework).
c) Create a code sub-folder (name it whatever you like.)
d) Within the code folder, create sub-folders for Domain, Repository, ViewModel, ThirdParty, and Tests.Unit.
e) Copy/paste the ButtonService.cs class code (from Details link, above) into the ThirdParty folder to provide a Command dependency property.
f) This project is now configured for wp7 unit testing and ICommand data binding (so you may want to save a copy of it for use as a template.)

Set your watch, and begin the kata:
1) Create a test class, CustomerViewModelTests, and add references to the unit test framework.
2) Create a test setup method, in which you instantiate a FakeCustomerRepository class to the ICustomerRepository instance variable.
3) Test that a (new) Customer domain entity and that ICustomerRepoository are passed as constructor parameters to CustomerViewModel.
4) Test that Customer has FirstName/LastName properties, and that CustomerViewModel has FirstName/LastName properties whose values are equal (hint: they WRAP, not duplicate, the Customer properties).
5) Test that a new method CustomerViewModel.VerifyPropertyName(string propertyName) throws an exception if a property name passed to it doesn't exist.
6) Test that CustomerViewModel is instance of type INotifyPropertyChanged.
7) Test that each time properties of the Customer domain entity are changed
* that the PropertyChangedEvent has been raised,
* that the equivalent view model properties have also changed
8) Refactor (move) the INotifyPropertyChanged interface and related methods to ViewModelBase, and then change CustomerViewModel to extend ViewModelBase. Ensure that all tests are still passing.
9) Create another test class, CustomerSaveCommandTests.cs, and add references to the unit test framework.
10) In CustomerSaveCommand, duplicate the ICustomerRepository instance variable and test setup method from CustomerViewModel.
11) Test that Customer and ICustomerRepoository are passed as constructor parameters to CustomerSaveCommand.
12) Test that CustomerSaveCommand is instance of type ICommand.
13) Reference CustomerSaveCommand as a new property of CustomerViewModel, the SaveCommand property.
14) Return to the CustomerViewModelTests class, and verify that customerViewModel.SaveCommand.CanExecute(null) returns false when the nested Customer FirstName and LastName properties are null or empty, else returns true.
15) Create test for CustomerViewModel.CustomerSaveCommand.Execute() method which verifies that
the nested _customerRepository.SaveCustomer() method had been called. Since you are using a fake instead of a mock, add a boolean property, FakeCustomerRepository.SaveMethodCalled which verifies that the repository Save method has been called.
16) Ensure that all tests are passing.

POST-SCRIPT: Connecting the presentation layer to the view model
17) Switch off the unit testing framework in the MainPage.xaml.cs class constructor (set runUnitTests to false).
18) Go to MainPage.xaml ann add an XML namespace reference to the ViewModel namespace.
19) Add another XML namespace reference to the ThirdParty namespace.
20) In the code-behind (MainPage.xaml.cs), in the constructor, instantiate CustomerViewModel (with a Customer parameter whose FirstName/LastName properties are empty) and assign the view model instance to this.DataContext.
21) In MainPage.xaml, in the lower Grid element, drag 2 TextBox controls and a Button to the Phone GUI design surface.
22) Add two-way binding between each TextBox and the corresponding properties of CustomerViewModel.
23) Add a customer property thirdParty:ButtonService.Command="{Binding Path=SaveCommand}" to the Button (i.e. the path is the name of the CustomerViewModel.SaveCommand property.)
24) Set a breakpoint on FakeCustomerRepository.SaveCustomer()
25) Run the Windows Phone emulator.
26) Add FirstName and LastName values.
27) Verify that when the Button is clicked, that this method is called with a Customer parameter containing the FirstName/LastName values you entered.

You're done!

xUnit Frameworks incompatible with Silverlight for Windows Phone 7 (.NET Compact Framework)

2010-03-23T09:29:00.000-07:00

When I first started building my blog entry on Building a Windows Phone 7 app with MVVM pattern, using TDD and mock objects, I started out using VS 2010 RC and NUnit, using the project templates from the Silverlight for Windows Phone project. I didn't get far through my tests until I hit testing with ICommand (for MVVM) and hit a show-stoppping error. At that point, I switched over to using Visual Studio 2010 Express for WinPhone and the Silverlight Unit Testing Framework.

Some discussions came up yesterday about what exactly Silverlight for Win Phone 7 (which runs under .NET Compact Framework) would and wouldn't support. Essentially most xUnit frameworks theoretically won't work because there is no support for Reflection.Emit in NETCF.

I wanted to go back and confirm what the error was I had hit with NUnit, so I redid the project in scratch in VS 2010 RC with NUnit and took it as far as it would go. As before, it hit the wall with ICommand. Here is the error that is generated:

Building a Windows Phone 7 app with MVVM pattern, using TDD and mock objects

2010-03-20T10:15:00.000-07:00

If you've worked through the long form already, try the short form (instructions only).

*****

Source code for this kata published to github.

The goal of this article is to take you through the process of creating a Windows Phone 7 app using Test-Driven Development, designing each feature of the app through a series of incremental tests. The concept is loosely modeled on the TDD Calculator kata as explained by Roy Osherove, although introducing an entire framework, with as many steps as required in the instructions below, moves outside the boundaries of a properly focused kata to what might more properly be called a tutorial. However, my goal is that these steps could be repeatedly practised, like a kata, to develop a consistent approach to TDD using the Windows Phone 7 unit testing framework.

To be able to test effectively in the presentation layer, we want to use the appropriate pattern. The pattern for XAML frameworks (WPF, Silverlight, and now Windows Phone 7) is the Model-View-ViewModel (MVVM) design pattern, in which the ViewModel is isolated from the presentation layer and therefore testable (much like the controller in the MVC pattern, or presenter in the MVP pattern.) The difference here is that the passing of data back and forth between ViewModel and View is done by the framework itself, using a data binding implementation. (This will get much clearer as you work through the tests.)

The initial tests will build the ViewModel itself, ensuring that it has all the pieces its need (implemented interfaces, constructor parameters, and so on) to perform its role in the MVVM pattern. Items not directly part of the SUT (system under test) will be mocked in.

NOTE Like many presentation layer patterns, we will want to use mock objects to substitute classes that are not directly part of the system under test (in this case, the ViewModel.) However, Windows Phone 7 runs on the .NET Compact Framework, which does not support full mocking frameworks such as Rhino Mocks and Moq. Therefore, in this kata we will create fakes (custom mock classes) to verify the repository queries have been called. As per the terminology used by Gerard Meszaros (see Mocks, Fakes, Stubs and Dummies) perhaps the best term to describe what we are building for our custom mock is a "Test Spy".

So let's get started.

Pre-Requisite: Install Windows Phone 7 Unit Testing Framework
To unit test a Windows Phone 7 application, as pre-requisite you must install and configure the Windows Phone 7-specific version of the Silverlight unit testing framework (in which test results are displayed directly in the Winodws Phone emulator screen.) NUnit and other xUnit testing frameworks are not currently compatible with Silverlight and Windows Phone 7.

To install:
1) Download/install Visual Studio 2010 Express for Windows Phone from here.
2) Download the zip file containing the 2 unsigned DLLs from Jeff Wilcox's website.
3) Unzip the 2 DLLs. Then, right-click each DLL individually and select "Properties".
4) In the Properties window for each DLL, click the "Unblock" button. (DLLs off the net are blocked for safety by default.)
5) Launch Visual Studio 2010 Express for Windows Phone.
6) Create a new solution where the project type is "Windows Phone Application"
7) In the Windows Phone Application project, add References for the 2 DLLs that you have just unblocked to this Windows project:

Microsoft.Silverlight.Testing
Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight

8) DON'T create any separate class library projects. For now, the unit testing framework requires that all tests/supporting classes be INSIDE the Windows project.
9) DO create a sub-folder in the Windows project, and give it a name to imply this is the application code (it will display in the namespace path). (examples: "AppCode" or "Support")
10) Finally, for the test framework to recognize your tests, you must add code to the code-behind class for the MainPage XAML file.
11) Open the file MainPage.xaml.cs
12) Add using statements to the Silverlight Unit Testing Framework DLLs you referenced earlier:


using Microsoft.Phone.Controls;
using Microsoft.Silverlight.Testing;

13) FINALLY, add the following lines of code (thanks to Jeff Wilcox for this) at the end of the constructor, just below the SupportedOrientations assignment. Note that we have declared a boolean constant (runUnitTests) which we've assigned to true, and then wrapped the code which initializes the unit testing framework into a conditional block based on this constant. With this constant set to true, the Windows Phone emulator will display the test results from the test runner. Later, when we want to view the phone app itself, we'll be setting this constant to false.


const bool runUnitTests = true;

if (runUnitTests)
{
    Content = UnitTestSystem.CreateTestPage();
    IMobileTestPage imtp = Content as IMobileTestPage;

    if (imtp != null)
    {
        BackKeyPress += (x, xe) => xe.Cancel = imtp.NavigateBack();
    }
}

14) Proceed to the TDD kata.

TDD Kata Setup
Within the application code sub-folder (created in the pre-requisites above), create the following sub-folders to function as namespaces: Domain, Repository, ViewModel, and Tests.Unit.

When completed, your SolutionExplorer should look like this:

Test #1 (ViewModel injects corresponding domain entity)
1) In the Tests.Unit sub-folder, create CustomerViewModelTests.cs class.
2) Add the following using statements:


using Microsoft.Silverlight.Testing.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;

3) Add the [TestClass] attribute to class. (Silverlight Unit Testing Framework is built on top of the MSTest framework, hence the naming convention for the test attributes is the same.)
4) The first test will requite a customer repository, so declare a private instance variable of non-existent type ICustomerRepository.


private ICustomerRepository _customerRepository;

5) Use the Visual Studio 2010 Generate from Usage feature to create the interface:

click into the type name, press Alt-Shift-F10
select "Generate new type...'"
In the Generate New Type dialog (see above), be sure to change the definition to interface, and then click OK.
In SolutionExplorer, select the ICustomerRepository class that has been generated in the Tests.Unit folder and use cut-and-paste to MOVE it into the Repository folder
In the Repository folder, double-click to open ICustomerRepository and fix its namespace declaration to be for the Repository folder.
Return to the test class; where the type reference is now broken
click on the type ICustomerRepository and press Alt-Shift-F10 to add a proper reference to the Repository namespace.

6) Create a test setup method.


[TestInitialize]
public void SetUp()
{
}

7) In the setup method, instantiate the _customerRepository interface as a new class, FakeCustomerRepository. Use Alt-Shft-F10 (Generate By Usage) to create this class. In the class signature, add ICustomerRepository as its implemented interface. Now move the class (cut-and-paste it within SolutionExplorer to move it to the Repository folder. Don't forget to edit its namespace entry to match the Repository.)


[TestInitialize]
public void SetUp()
{
    _customerRepository = new FakeCustomerRepository();
}

8) Create a test for CustomerViewModel, in which _customerRepository and a new instance of Customer are passed as parameters to the constructor. Since Customer is a new class; use Alt-Shft-F10 (Generate By Usage) to create the class, and to initialize FirstName and LastName properties. In Solution Explorer, cut-and-paste to move this class to the Domain sub-folder, then edit its namespace declaration to match.


[TestMethod]
public void Constructor_CustomerAndRepositoryInput_InstantiatesSuccessfully()
{
    var customer = new Customer { FirstName = "June", LastName = "Wong" };
    var sut = new CustomerViewModel(_customerRepository, customer);
    Assert.IsNotNull(sut);
}

NOTE It is common in tests to keep track of which class is the "System Under Test" by naming the class variable "sut". The supplied code snippets will use this convention.

9) You are ready for your first test run using the Windows Phone 7 unit test framework. Right-click on the solution, and click "Deploy Solution". The test should pass, displaying as follows:

NOTE The items listed in the test results can be drilled-down into for more detail. Click the item to drill-down, click the back arrow icon at the bottom of the phone emulator to go back.

Test #2 (ViewModel property values match domain property values)
10) The correct implementation of the MVVM pattern is the ViewModel "wraps" the model (i.e the domain.) Therefore a domain entity, Customer, should have it's properties exposed, but not replicated, through the ViewModel. Therefore, create test for CustomerViewModel which verifies that:
* Customer.FirstName is wrapped by CustomerViewModel.FirstName
* Customer.LastName is wrapped by CustomerViewModel.LastName


[TestMethod]
public void Constructor_CustomerAndRepositoryInput_CustomerPropertiesEqualViewModelProperties()
{
    var customer = new Customer { FirstName = "June", LastName = "Wong" };
    var sut = new CustomerViewModel(_customerRepository, customer);

    Assert.AreEqual(customer.FirstName, sut.FirstName);
    Assert.AreEqual(customer.LastName, sut.LastName);
}

CustomerViewModel properties


public string FirstName
{
    get
    {
        return _customer.FirstName;
    }
    set
    {
        _customer.FirstName = value;
    }
}

public string LastName
{
    get
    {
        return _customer.LastName;
    }
    set
    {
        _customer.LastName = value;
    }
}

Test #3 (ViewModel.VerifyPropertyName(string property))
11) Create test for CustomerViewModel which verifies that the VerifyPropertyName(string property) throws a custom exception if the property is not part of the model.


[TestMethod]
[ExpectedException(typeof(VerifyPropertyNameException))]
public void VerifyPropertyNameMethod_NonExistentPropertyString_ThrowsException()
{
    var customer = new Customer() { FirstName = "June", LastName = "Smith" };
    var sut = new CustomerViewModel(_customerRepository, customer);
    sut.VerifyPropertyName("NonExistentPropertyName");
}

corresponding method


public void VerifyPropertyName(string propertyName)
{
    foreach(var propertyInfo in this.GetType().GetProperties())
    {
        if(propertyName == propertyInfo.Name)
        {
            return;
        }
    }
    throw new VerifyPropertyNameException();
}

corresponding method, refactored to LINQ


public void VerifyPropertyName(string propertyName)
{
    if (this.GetType().GetProperties().Any(propertyInfo => propertyInfo.Name.Equals(propertyName)))
    {
        return;
    }
    throw new VerifyPropertyNameException();
}

Test #4 (ViewModel implements INotifyPropertyChanged)
12) Create test for CustomerViewModel which verifies that CustomerViewModel is (of type) INotifyPropertyChanged.


[TestMethod]
public void Constructor_CustomerInput_ImplementsINotifyPropertyChanged()
{
    var customer = new Customer() { FirstName = "June", LastName = "Smith" };
    var customerViewModel = new CustomerViewModel(customer);
    Assert.IsInstanceOfType(customerViewModel, typeof(INotifyPropertyChanged));
}

Test #5 (ViewModel.PropertyChanged Event fires when ViewModel property setters called)
13) Create test for CustomerViewModel which verifies that after FirstName/LastName properties have been changed, that the PropertyChanged event has fired.


[TestMethod]
public void ClassProperties_WhenSet_PropertyChangedEventFires()
{
    var customer = new Customer();
    var sut = new CustomerViewModel(_customerRepository, customer);
    var receivedEvents = new List();
    sut.PropertyChanged += ((sender, e) => receivedEvents.Add(e.PropertyName));

    sut.FirstName = "Sabrina";
    Assert.AreEqual(1, receivedEvents.Count);
    Assert.AreEqual("FirstName", receivedEvents[0]);
    sut.LastName = "Moore";
    Assert.AreEqual(2, receivedEvents.Count);
    Assert.AreEqual("LastName", receivedEvents[1]);
}

event raising implementation


protected virtual void OnPropertyChanged(string propertyName)
{
    this.VerifyPropertyName(propertyName);

    var handler = this.PropertyChanged;
    if (handler == null) return;
    var e = new PropertyChangedEventArgs(propertyName);
    handler(this, e);
}

example of call to OnPropertyChanged within a property setter


public string FirstName
{
    get
    {
        return _customer.FirstName;
    }
    set
    {
        _customer.FirstName = value;
        OnPropertyChanged("FirstName");
    }
}

Test #6 (Domain entity properties stay in sync when ViewModel property setters called)
14) Create test for CustomerViewModel which verifies that after FirstName/LastName properties have been changed, that the Customer domain entity properties still match (i.e. have stayed in sync.).


[TestMethod]
public void DomainProperties_ReassignedValues_ViewModelPropertiesTrackChanges()
{
    var customer = new Customer() { FirstName = "June", LastName = "Smith" };
    var sut = new CustomerViewModel(_customerRepository, customer);

    Assert.AreEqual(customer.FirstName, sut.FirstName);
    Assert.AreEqual(customer.LastName, sut.LastName);

    customer.FirstName = "New First Name";
    customer.LastName = "New Last Name";

    Assert.AreEqual(customer.FirstName, sut.FirstName);
    Assert.AreEqual(customer.LastName, sut.LastName);
}

15) Refactoring: Move the interface, the PropertyChanged event, and all related methods into a superclass, ViewModelBase. Ensure that all tests are still passing.


public abstract class ViewModelBase : INotifyPropertyChanged
{
    public void VerifyPropertyName(string propertyName)
    {
        foreach(var propertyInfo in this.GetType().GetProperties())
        {
            if(propertyName == propertyInfo.Name)
            {
                return;
            }
        }
        throw new VerifyPropertyNameException();
    }

    public virtual event PropertyChangedEventHandler PropertyChanged;

    protected virtual void OnPropertyChanged(string propertyName)
    {
        this.VerifyPropertyName(propertyName);

        var handler = this.PropertyChanged;
        if (handler == null) return;
        var e = new PropertyChangedEventArgs(propertyName);
        handler(this, e);
    }
}

With all 6 tests passing, the Windows Phone emulator should display the tests as follows:

You are now ready to add event-handling to the ViewModel, by way of command classes.
Test #7 (CustomerSaveCommand implements ICommand)
16) Create CustomerSaveCommandTests.cs class
17) Add the following using statements:


using Microsoft.Silverlight.Testing.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;

18) You will need the same FakeCustomerRepository instance for your tests, so copy the instance variable and the test setup method from the CustomerViewModelTests class.


private ICustomerRepository _customerRepository;

[TestInitialize]
public void SetUp()
{
    _customerRepository = new FakeCustomerRepository();
}

19) Create test for CustomerSaveCommand which passes the _customerRepository instance, and a new Customer instance, as parameters to the constructor, then verifies that CustomerSaveCommand is (of type) ICommand.


[TestMethod]
public void Constructor_CustomerRepositoryInput_ImplementsICommand()
{
    var customer = new Customer() { FirstName = "June", LastName = "Smith" };
    var sut = new CustomerSaveCommand(_customerRepository, customer);
    Assert.IsInstanceOfType(sut, typeof(ICommand));
}

Test #8 (CustomerViewModel.CustomerSaveCommand.CanExecute returns true when Customer is valid, false when Customer is not)
You will now attach CustomerSaveCommand as a property of the CustomerViewModel class, so the remaining tests will be written against CustomerViewModel.
20) Return to the CustomerViewModelTests.cs class.
21) Create a test for the CustomerViewModel.CustomerSaveCommand property which verifies that sut.CustomerSaveCommand.CanExecute(object param) is true.


[TestMethod]
public void CustomerSaveCommandPropertyCanExecute_ValidCustomer_ReturnsTrue()
{
    var customer = new Customer() { FirstName = "June", LastName = "Smith" };
    var sut = new CustomerViewModel(_customerRepository, customer);

    Assert.IsTrue(sut.CustomerSaveCommand.CanExecute(null));
}

22) Refactor the CustomerSaveCommand class so that the condition under which CanExecute(object param) is true is that the properties of the _customer instance all have saveable values (they aren't null or empty.)


public bool CanExecute(object parameter)
{
    return !string.IsNullOrEmpty(_customer.FirstName)
        && !string.IsNullOrEmpty(_customer.LastName);
}

23) Now test the reverse, where passing a Customer instance with empty FirstName/LastName properties to CustomerSaveCommand.CanExecute(object parameter) returns false.


[TestMethod]
public void CustomerSaveCommandPropertyCanExecute_InvalidCustomer_ReturnsTrue()
{
    var customer = new Customer() { FirstName = "", LastName = "" };
    var sut = new CustomerViewModel(_customerRepository, customer);

    Assert.IsFalse(sut.CustomerSaveCommand.CanExecute(null));
}

Test #9 (CustomerViewModel.CustomerSaveCommand.Execute saves the Customer record)
20) Create test for CustomerViewModel.CustomerSaveCommand.Execute() method which verifies that the _customerRepository.SaveCustomer() method had been called.
NOTE Since we can't use a mocking framework such as RhinoMocks in .NET Compact Framework, we will add a test-only property to ICustomerRepository called SaveMethodWasCalled; set to false in the repository constructor, and set to true in the ICustomerRepository.SaveCustomer(Customer customer) method.


[TestMethod]
public void CustomerSaveCommandPropertyExecute_ValidCustomer_RepositoryValidatesCallOccured()
{
    var customer = new Customer() { FirstName = "June", LastName = "Smith" };
    var sut = new CustomerViewModel(_customerRepository, customer);

    sut.CustomerSaveCommand.Execute(null);
    Assert.IsTrue(_customerRepository.SaveCommandCalled);
}

CustomerSaveCommand.Execute() code


public void Execute(object parameter)
{
    if (this.CanExecute(null))
    {
        _customerRepository.SaveCustomer(_customer);
    }
}

FakeCustomerRepository.SaveCustomer() method code


public void SaveCustomer(Customer customer)
{
    // call to not-yet-created WCF client web method
    _saveCommandCalled = true;
}

22) In Solution Explorer, right-click on the solution and choose "Deploy Solution". All 10 tests should be passing. Click on either test class in the Win Phone 7 emulator window to view the complete list of tests.

With all tests passing, you are ready to proceed to the final step - hooking up the ViewModel to the XAML presentation layer.

[Postscript - Building the XAML presentation layer mapped to ViewModel]

23) In Solution Explorer, double-click MainPage.xaml to open it. Adjust the split view between the design and XAML views so that you can easily edit the XAML.
24) In the <phoneNavigation> element, after the xmlns:x attribute, type xmlns:vm= and Intellisense will appear with a list of optional namespaces containing the viewmodel. Press the down arrow to select the ViewModel namespace (as shown below), and then press Enter.

25) Your viewmodel namespace reference should now look like this:

25) Next, you must associate the DataContext of MainPage.xaml to the specific view model class for this page, which is CustomerViewModel.cs. This can be achieved declaratively in the <UserControl.Resources> element of the XAML, but only when your view model has a parameterless constructor. For CustomerViewModel, we will need to associate the DataContext in the code-behind class. To do this, go to the first test you created in CustomerViewModelTests, and copy the instantiation code. Paste it at the end of the MainPage constructor. You'll need to use Alt-Shft-F10 to resolve various references to your classes, and add an instantiation to FakeCustomerRepository (This could be switched out for a "real" repository class later, eg. one built as a wrapper for a web service proxy addressing your web service layer.). When you are done, the data context assignment code should look like this:


ICustomerRepository customerRepository = new FakeCustomerRepository();
var customer = new Customer();
var customerViewModel = new CustomerViewModel(customerRepository, customer);
this.DataContext = customerViewModel;

26) Drag 2 TextBox controls with labels (i.e. TextBlock controls) and a Button onto the design surface. Apply names and pretty-fication until it looks something like this:

27) Add the following attribute to the corresponding XML element for each TextBox (where Path equals the property name from the ViewModel)
for txtFirstName control


Text="{Binding Path=FirstName, Mode=TwoWay}"

for txtLastName control


Text="{Binding Path=LastName, Mode=TwoWay}"

28) You are now ready to add binding to the "SaveCustomer" button.
NOTE At this point, in WPF, the Button's Command property could be set to the data binding for the SaveCustomerCommand class. However, the Command property doesn't exist in Silverlight. This issue has been addressed in a blog entry by Patrick Cauldwell. In the steps below, his ButtonService class is used to provide support for a custom Command binding attribute.

29) Download Patrick Cauldwell's code zip (located at bottom of his blog entry.)
30) Extract the code zip, and locate the ButtonService.cs class.
31) Add a new folder/namespace to your existing folders, named "ThirdParty". Drag and drop ButtonService.cs into this folder.
32) Open the ButtonService.cs class, and change the namespace to match the path of your folder.
NOTE 2010Mar27 As of this writing, there is a TYPO in the ButtonService.cs class. In the initial static registration of the CommandParameterProperty, the 2nd parameter (see code snippet below) is set to typeof(string). This will cause a null error later, in the event raising method, when attempting to cast the command instance to ICommand (because it incorrectly being passed as string.) Therefore, CHANGE the 2nd parameter to be typeof(ICommand).


public static readonly DependencyProperty CommandParameterProperty =
        DependencyProperty.RegisterAttached("CommandParameter", typeof(string), typeof(ButtonService),
        new PropertyMetadata(OnCommandParameterChanged));

33) In MainPage.xaml, you need to add an alias to this namespace (similar to the xmlns:vm namespace you created earlier.) eg. "thirdParty". Add this directly below the xmlns:vm namespace reference.


xmlns:thirdParty="clr-namespace:CustomerApp.Support.ThirdParty"

34) Add a new attribute to the <Button> element to provide data binding to the CustomerSaveCommand.
NOTE 2010Mar27 Path must be bound to the ViewModel's property name, NOT the property type (if they are different; for example, if the property were CustomerViewModel.Save of property type CustomerSaveCommand, then the correct binding path would be "Save").


thirdParty:ButtonService.Command="{Binding Path=CustomerSaveCommand}"

35) You now need to turn off your tests to run your application. BEFORE you do that, run your tests one more time and make sure that all tests are passing.
36) With all tests passing, let's run the application now instead of the tests. To do this, go back to the MainPage.xaml.cs and switch the boolean constant (runUnitTests) to false:


const bool runUnitTests = false;

37) In the FakeCustomerRepository.cs, set a breakpoint on the line of code within the SaveCustomer() method.
38) Finally, launch the application. Enter values into the FirstName and LastName fields, and press the SaveButton.
49) Observe that the breakpoint is hit, the Customer is being passed correctly to the Customer repository's Save command, and the value of the Customer FirstName and LastName properties match the values you entered into the TextBox controls in the XAML layer.

Your Win Phone 7 application using MVVM and unit tests is now complete.

Steps to run the Windows Phone 7 Unit Test Framework successfully

2010-03-19T18:56:00.000-07:00

Thanks to assistance from Jeff Wilcox of Microsoft, I now have the Windows Phone 7 Unit Test Framework running successfully!

Here are the steps to get it running:

1) Download/install Visual Studio 2010 Express for Windows Phone from here.
2) Download the zip file containing the 2 unsigned DLLs from Jeff Wilcox's website.
3) Unzip the 2 DLLs. Then, right-click each DLL individually and select "Properties".
4) In the Properties window for each DLL, click the "Unblock" button. (DLLs off the net are blocked for safety by default.)
5) Launch Visual Studio 2010 Express for Windows Phone and create a new Windows Phone project.
6) Add References to the 2 DLLs that you have just unblocked to this Windows project:
* Microsoft.Silverlight.Testing
* Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight
8) DON'T create any separate class libraries. For now, the unit testing framework requires that all tests/supporting classes be INSIDE the Windows project.
9) DO create a sub-folder in the Windows project to hold code (eg. "CodeLibrary").
10) Create a sub-folder within "CodeLibrary", and name it "Tests".
11) Add a class to the Tests folder, named something like "CustomerViewModelTests.cs"
12) In the class, add the following using statements:


using Microsoft.Silverlight.Testing.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;

13) Add the [TestClass] attribute above the class declaration.
14) Create a test method with the [TestMethod] attribute, something like this:


[TestMethod]
public void Constructor_CustomerInput_IsHappy1()
{
    Assert.IsTrue(true, "It worked!");
}

15) Finally, for the test framework to recognize your tests, you must add code to the code-behind class for the MainPage XAML file.
16) Open the file MainPage.xaml.cs
17) Add the same 2 using statements that you added to the test class:


using Microsoft.Phone.Controls;
using Microsoft.Silverlight.Testing;

18) Add the following lines of code (thanks to Jeff Wilcox for this) at the end of the constructor, just below the SupportedOrientations assignment


const bool runUnitTests = true;

if (runUnitTests)
{
    Content = UnitTestSystem.CreateTestPage();
    IMobileTestPage imtp = Content as IMobileTestPage;

    if (imtp != null)
    {
        BackKeyPress += (x, xe) => xe.Cancel = imtp.NavigateBack();
    }
}

19) Create another folder within the "CodeLibrary" sub-folder named "ThirdParty".
20) Within this folder, create a class called "ButtonService.cs" and paste in the following code. This code comes from Patrick Cauldwell's blog entry here; it adds support for binding ICommand classes to controls via a custom attribute, Command. The Command attribute is a standard feature in WPF and later versions of Silverlight, but not available by default in the Windows Phone 7 implementation of Silverlight:


public static class ButtonService
{
    // Modified from Patrick Cauldwell's original ButtonService class
    // here: http://www.cauldwell.net/patrick/blog/MVVMBindingToCommandsInSilverlight.aspx

    private static readonly DependencyProperty _commandProperty;

    static ButtonService()
    {
         _commandProperty = DependencyProperty.RegisterAttached("Command", typeof(ICommand), typeof(ButtonService),
            new PropertyMetadata(OnCommandChanged));
    }

    public static ICommand GetCommand(DependencyObject dependencyObject)
    {
        return (ICommand)dependencyObject.GetValue(_commandProperty);
    }

    public static void SetCommand(DependencyObject dependencyObject, ICommand value)
    {
        dependencyObject.SetValue(_commandProperty, value);
    }

    private static void OnCommandChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs dpceArgs)
    {
        if (dependencyObject is Button)
        {
            string parameter = dependencyObject.GetValue(_commandProperty).ToString();
            Button button = (Button)dependencyObject;
            ICommand command = (ICommand)dpceArgs.NewValue;
            button.Click += delegate(object sender, RoutedEventArgs arg) { command.Execute(parameter); };
        }
    }
}

20) Your environment is now configured! Proceed to the tutorial: Building a Windows Phone 7 app with MVVM pattern, using TDD and mock objects.

This blog post has been updated

2010-03-16T09:12:00.000-07:00

This blog post has been updated and moved to here:

Windows Phone 7 TDD Kata using MVVM and Custom Mocks.

TDD kata for ASP.NET MVC controllers (part 2)

2010-03-13T15:52:00.000-08:00

The purpose of this kata is to get practice in working with each ActionResult type that is returned from the controller. As before, the controller is tested in isolation (you do not create an actual ASP.NET MVC project, just a class library containing controllers and references to System.Web.Mvc).

In part 1, you set up the test project and related projects, and worked with the following return types derived from ActionResult:
1) ViewResult with ViewData
2) ViewResult with ViewData.Model
3) The same, with a mocked repository
4) RedirectToRouteResult

In part 2, we work with the following additional return types derived from ActionResult:
* RedirectToRouteResult, with TempData
* PlainText (just a string)
* ContentResult (as plain text)
* ContentResult (as RSS feed)
* JsonResult
* JavaScriptResult

If you haven't already completed part 1 of this kata, you can go there now by clicking here.

With part 1 completed, you should have a solution with 4 projects (Tests.Unit, Controllers, Domain, and Repository.) Your tests and controllers projects should have references to System.Web.Mvc and System.Web.Mvc.Routing; all of your controllers should inherit from the Controller base class.

You are now ready to proceed forward into part 2. I'll continue the numbering for tests and steps as of end of part 1:

Test #5 (RedirectToRouteResult with TempData)
17) In HelpTopicsController.cs class, modify the existing method call to also assign a TempData message.
18) In the existing test, assert that the controller instance TempData property has an expected key/value pair, for example: sut.TempData["message"] = "My cross-page message."
Test #6 (Plain Text - just a string)
19) Create TextOutputControllerTests.cs class.
20) Create test for TextOutputController.
21) Call TextOutputController.ShowPlainText(string text) and return the string parameter directly (no casting.)
22) Assert that the returned method string matches input parameter string.
Test #7 (Plain Text as ContentResult)
23) Create another test for TextOutputController.
24) Call TextOutputController.ShowContentResultPlainText(string text) and return Content() as ActionResult.
25) In test, cast the method return to ContentResult.
26) Assert that contentResult.ContentType = "text/plain".
27) Assert that contentResult.Content matches the input string.
Test #8 (RSS feed as ContentResult)
28) Create another test for TextOutputController.
29) Create instance of XDocument() named rssFeed.
30) Call TextOutputController.ShowContentResultRSS(XDocument rssFeed) and return Content(XDocument rssFeed, string contentType) as ContentResult.
31) In test, cast the method return to ContentResult.
32) Assert that contentResult.ContentType = "application/rss+xml".
33) Assert that contentResult.Content matches rssFeed.
Test #9 (JsonResult)
34) Create JsonOutputControllerTests.cs class.
35) Create a test for JsonOutputController.
36) Create instance of List (you created Customer in the Domain namespace in part 1.
37) Use object initializers to add FirstName and LastName property values to 2 instances of Customer in this list.
38) Call JsonOutputController.ShowJsonResult(List customers) and return Json(customers) as ActionResult.
39) In test, cast the method return to JsonResult.
39) In test, cast jsonResult.Data to List with variable name: jsonCustomers.
40) Assert that customers[0] is same as jsonCustomers[0]. (To do this, you will need to override Equals() and GetHashCode() on Customers where equality is based on FirstName and LastName properties.)
Test #10 (JavascriptResult)
41) Create JavaScriptOutputControllerTests.cs class.
42) Create a test for JavaScriptOutputController.
43) Create a simple JavaScript and assign to string javaScriptString eg. "alert('Greetings!');"
44) Call JavaScriptOutputController.OutputJavaScript(string javaScriptString) and return JavaScript(javaScriptString) as JavaScriptResult.
45) Assert that javaScriptString and javaScriptResult.Script are equal.

This demonstrates all returned ActionResult types from controllers (other than file/streaming output types) for ASP.NET MVC v1.

Below are code samples for each of the above tests and controllers.

HelpTopicsControllerTests.cs


[TestFixture]
public class HelpTopicsControllerTests
{
    [Test]
    public void GetHelpMethod_TopicInput_ReturnsRedirectRouteValues()
    {
        const string helpTopic = "searching";
        var sut = new HelpTopicsController();
        var redirectToRouteResult = (RedirectToRouteResult)sut.GetHelp(helpTopic);

        Assert.AreEqual("helpTopic", redirectToRouteResult.RouteValues["controller"]);
        Assert.AreEqual("index", redirectToRouteResult.RouteValues["action"]);
        Assert.AreEqual(helpTopic, redirectToRouteResult.RouteValues["helpTopic"]);
    }

    [Test]
    public void GetHelpWithInfoMethod_TopicInput_ReturnsRedirectTempData()
    {
        const string helpTopic = "searching";
        const string additionalMessage = "My cross-page message";
        var sut = new HelpTopicsController();
        var redirectToRouteResult = (RedirectToRouteResult)sut.GetHelpPlusAdditionalMessage(helpTopic, additionalMessage);

        Assert.AreEqual(additionalMessage, sut.TempData["message"]);
    }
}

HelpTopicsController.cs


public class HelpTopicsController : Controller
{
    public RedirectToRouteResult GetHelp(string helpTopic)
    {
        return RedirectToAction("index", "helpTopic", new { helpTopic = helpTopic });
    }

    public RedirectToRouteResult GetHelpPlusAdditionalMessage(string helpTopic, string additionalMesage)
    {
        TempData["message"] = additionalMesage;
        return RedirectToAction("index", "helpTopic", new { helpTopic = helpTopic });
    }
}

TextOutputControllerTests.cs


[TestFixture]
public class TextOutputControllerTests
{
    [Test]
    public void ShowPlainTextMethod_NoInputParameters_ReturnsPlainText()
    {
        var sut = new TextOutputController();
        const string somePlainText = "This is plain text";
        var plainTextOutput = sut.ShowPlainText(somePlainText);

        Assert.AreEqual(somePlainText, plainTextOutput);
    }

    [Test]
    public void ShowContentResultPlainTextMethod_NoInputParameters_ReturnsContentResultAsTextPlain()
    {
        var sut = new TextOutputController();
        const string somePlainText = "This is plain text";
        var contentResult = (ContentResult)sut.ShowContentResultPlainText(somePlainText);

        Assert.AreEqual("text/plain", contentResult.ContentType);
        Assert.AreEqual(somePlainText, contentResult.Content);
    }

    [Test]
    public void ShowContentResultRSSMethod_RSSFeedInputParameters_ReturnsContentResultAsRSS()
    {
        var sut = new TextOutputController();
        var rssFeed = new XDocument();
        var contentResult = (ContentResult)sut.ShowContentResultRSS(rssFeed);

        Assert.AreEqual("application/rss+xml", contentResult.ContentType);
        Assert.AreEqual(rssFeed.ToString(), contentResult.Content);
    }
}

TextOutputController.cs


public class TextOutputController : Controller
{
    public string ShowPlainText(string text)
    {
        return text;
    }
    
    public ActionResult ShowContentResultPlainText(string text)
    {
        return Content(text, "text/plain");
    }

    public ContentResult ShowContentResultRSS(XDocument rssFeed)
    {
        return Content(rssFeed.ToString(), "application/rss+xml");
    }
}

JsonOutputControllerTests.cs


[TestFixture]
public class JsonOutputControllerTests
{
    [Test]
    public void ShowJsonResultMethod_CustomerInputParameters_ReturnsJsonArray()
    {
        var sut = new JsonOutputController();
        var customers = new List
                            {
                                new Customer {FirstName = "June", LastName = "Jones"},
                                new Customer {FirstName = "Gary", LastName = "Li"}
                            };
        var jsonResult = (JsonResult)sut.ShowJsonResult(customers);
        var jsonCustomers = (List)jsonResult.Data;

        Assert.AreEqual(customers[0], jsonCustomers[0]);
        Assert.AreEqual(customers[1], jsonCustomers[1]);
    }
}

Customer.cs


public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public override bool Equals(object obj)
    {
        var other = (Customer) obj;
        return other.FirstName.Equals(this.FirstName)
               && other.LastName.Equals(this.LastName);
    }

    public override int GetHashCode()
    {
        return this.FirstName.GetHashCode() + this.LastName.GetHashCode();
    }
}

JsonOutputController.cs


public class JsonOutputController : Controller
{
    public ActionResult ShowJsonResult(List customers)
    {
        return Json(customers);
    }
}

JavaScriptOutputControllerTests.cs


[TestFixture]
public class JavaScriptOutputControllerTests
{
    [Test]
    public void GreetingsMethod_NoInput_ReturnsJavaScriptResult()
    {
        var sut = new JavaScriptOutputController();
        const string javaScriptString = "alert('Greetings!');";
        var javaScriptResult = sut.OutputJavaScript(javaScriptString);

        Assert.AreEqual(javaScriptString, javaScriptResult.Script);    
    }
}

JavaScriptOutputController.cs


public class JavaScriptOutputController : Controller
{
    public JavaScriptResult OutputJavaScript(string javaScriptString)
    {
        return JavaScript(javaScriptString);
    }
}

TDD kata for ASP.NET MVC controllers (part 1)

2010-03-06T12:00:00.000-08:00

The purpose of this kata is to work with ASP.NET MVC controllers in isolation: a simple class library that references System.Web.Mvc and creates classes that inherit from the Controller base class, and nothing more than that.

By doing this, the goal is to understand the features of the controller in isolation, without working with the rest of the framework. The main variations in the tests with be:
* which ActionResult type is returned
* use of the Model
* use of dependency injection for mock repositories

This blog post takes you through part 1; to continue to part 2, click here.

1) Create a solution with 4 projects:
   * Tests.Unit
   * Controllers
   * Domain
   * Repository
2) Reference System.Web.Mvc in the test and controllers projects
Test #1 (ViewResult with ViewData)
3) Create WelcomeControllerTests.cs class.
4) Create test for WelcomeController. (WelcomeController must inherit from System.Mvc.Controller.)
5) Call WelcomeController.Index() and cast it to ViewResult.
6) Assert that viewResult.ViewData["Message"] equals "Welcome".
Test #2 (ViewResult with ViewData.Model)
7) Create test for WelcomeController.DisplayCustomers(List<Customer> customers) and cast it to (ViewResult)
8) Assert that viewResult.ViewData.Model is same object as customers (List<Customer>).
Test #3 (ViewResult with ViewData.Model using DI mock repository)
9) Create CustomerControllerTests.cs class.
10) Create CustomerController with constructor that requires ICustomerRepository
11) Use mockCustomerRepository to verify that FindAllCustomers() returns customers as List<Customer>
12) Call CustomerController.DisplayCustomers() and cast to (ViewResult)
13) Assert that viewResult.ViewData.Model and customers are the same (equivalent) object.
Test #4 (RedirectToRouteResult)
14) Create HelpTopicsControllerTests.cs class.
15) Add a reference to System.Web.Routing, in 2 projects: Tests and Controllers.
16) Create test which validates that HelpTopicsController.GetHelp(string helpTopic) does the following:
    a) returns a RedirectToViewResult.
    b) Asserts that redirectToRouteResult.RouteValues for keys "controller", "action", and "helpTopic" return expected results. (see code sample below for specific values.)

WelcomeControllerTests.cs


[TestFixture]
public class WelcomeControllerTests
{
    [Test]
    public void IndexMethod_NoParameters_ReturnsViewResultMessageWelcome()
    {
        var welcomeController = new WelcomeController();
        var viewResult = (ViewResult)welcomeController.Index();

        Assert.AreEqual("Welcome", viewResult.ViewData["Message"]);
    }

    [Test]
    public void DisplayCustomersMethod_CustomersListParameter_ReturnsCustomersAsModel()
    {
        var welcomeController = new WelcomeController();
        var customers = new List<Customer>();
        var viewResult = (ViewResult)welcomeController.DisplayCustomers(customers);

        Assert.AreSame(customers, viewResult.ViewData.Model);
    }
}

WelcomeController.cs


public class WelcomeController : Controller
{
    public ViewResult Index()
    {
        ViewData.Add("Message", "Welcome");
        return View();
    }

    public ViewResult DisplayCustomers(List<Customer> customers)
    {
        return View(customers);
    }
}

CustomerControllerTests.cs


[TestFixture]
public class CustomerControllerTests
{
    private MockRepository _mockRepository;
    private ICustomerRepository _mockCustomerRepository;

    [SetUp]
    public void SetUp()
    {
        _mockRepository = new MockRepository();
        _mockCustomerRepository = _mockRepository.StrictMock();
    }

    [TearDown]
    public void TearDown()
    {
        _mockRepository.ReplayAll();
        _mockRepository.VerifyAll();
    }

    [Test]
    public void FindAllCustomersMethod_NoParams_ReturnsCustomersAsModel()
    {
        var customerController = new CustomerController(_mockCustomerRepository);
        var customers = new List<Customer>();
        Expect.Call(_mockCustomerRepository.FindAll()).Return(customers);

        _mockRepository.ReplayAll();

        var viewResult = (ViewResult) customerController.FindAllCustomers();
        Assert.AreSame(customers, viewResult.ViewData.Model);
    }
}

CustomerController.cs


public class CustomerController : Controller
{
    private readonly ICustomerRepository _customerRepository;

    public CustomerController(ICustomerRepository customerRepository)
    {
        _customerRepository = customerRepository;
    }

    public ViewResult FindAllCustomers()
    {
        var customers = _customerRepository.FindAll();
        return View(customers);
    }
}

HelpTopicsControllerTests.cs


[TestFixture]
public class HelpTopicsControllerTests
{
    [Test]
    public void FindTopicMethod_StringInput_ReturnsRedirectToRouteResult()
    {
        const string helpTopic = "searching";
        var helpTopicsController = new HelpTopicsController();
        var redirectToRouteResult = helpTopicsController.GetHelp(helpTopic);

        Assert.AreEqual("helpTopic", redirectToRouteResult.RouteValues["controller"]);
        Assert.AreEqual("index", redirectToRouteResult.RouteValues["action"]);
        Assert.AreEqual(helpTopic, redirectToRouteResult.RouteValues["helpTopic"]);
    }
}

HelpTopicsController.cs


public class HelpTopicsController : Controller
{
    public RedirectToRouteResult GetHelp(string helpTopic)
    {
        return RedirectToAction("index", "helpTopic", new {helpTopic = helpTopic});
    }
}

TDD/Mocks with Model-View-Presenter compared to with ASP.NET MVC

2010-03-03T19:08:00.000-08:00

The last couple of months I've been learning mocks with Model-View-Presenter scenarios, and most recently, applying that to the TDD katas. This was always meant to be a precursor to applying the same concepts to ASP.NET MVC.

In the fall, I worked through the SportsStore demo for ASP.NET MVC in [Sandersen], and over my recent 2 weeks holidays I reviewed Sandersen as well as starting to read [Palermo], who also recommends the concept of a "Presentation" layer that represents a flattened view of the Model for simpler implementation within the View tags.

I am now starting to apply that knowledge by creating a TDD kata that starts (as always) with the domain, but then introduces controllers that originate purely within each test. Only then, as their requirement in the test leads to their generation by Resharper, are they refactored out into their own class files, and moved over into the Mvc project where the real Mvc hooks are added into the controller (a using statement for System.Mvc, inheritance from the base Controller class.)

The goal here is have true test by design (and generation by usage) in ASP.NET MVC, just as I did previously with the Model-View-Presenter scenarios.

The main difference I am seeing is that instead of mocking both the repository and the view, that I am mocking the repository only, since the View is managed by the ASP.NET MVC framework. Therefore, I am primarily concerned with asserts against the ViewData.Model, to make sure that it is the expected domain layer (or flattened presentation layer) object.

I'll be releasing a full TDD kata example in the next few days, but for now, here is an example of one of the tests:

InvoiceControllerTests.cs


[Test]
public void FindInvoice_InvoiceIdInput_ReturnsFlattenedInvoice()
{
    const string invoiceNumber = "1234";
    var invoice = new Invoice(invoiceNumber);
    Expect.Call(_mockInvoiceRepository.FindByInvoiceNumber(invoiceNumber)).Return(invoice);

    _mockRepository.ReplayAll();

    var invoiceController = new InvoiceController(_mockInvoiceRepository);
    var viewResult = (ViewResult) invoiceController.FindInvoiceByInvoiceNumber(invoiceNumber);

    var flattenedInvoice = (FlattenedInvoice) viewResult.ViewData.Model;

    Assert.AreSame(invoice, flattenedInvoice.Invoice);
}

Day 5 of 5 Day TDD Kata: "Invoice Presenter Adds and Displays Invoice with Taxes and Totals"

2010-02-08T19:39:00.000-08:00

And that's it: the 5 Day TDD Kata is now complete!

As before, I will only post a brief code sample below; full samples are posted to github here.

Here's the kata:

DAY 5: InvoicePresenter ADDS AND DISPLAYS INVOICE WITH TAXES AND TOTALS
The culmination. This kata works with everything you have built leading up to it.

Create a namespace for Repository.
Create CustomerTests. Verify when Customer adds an Invoice, that Customer.Invoices increments.
Create InvoicePresenterTests with 4 mocked interfaces: ITaxesRepository, ICustomerRepository, IInvoiceRepository, and IInvoiceView.
Create the following IInvoiceView events, each with a default EventHandler:
- GetCustomer event
- AddInvoiceLine event
- CalculateTotals event
- SaveInvoice event
For each one, verify that InvoicePresenter's constructor attaches that event to an event handler. (You can expect each event to be assigned to null, and instruct the mock to ignore the argument. For subsequent tests, you only need to get the event if the current test needs to verify behaviour that occurs when the event is raised.)
When GetCustomer event is raised, verify that
a) IInvoiceView.CustomerCode is assigned to ICustomerRepository.FindCustomerByCode().
b) the returned Customer is retrieved, and FirstName and LastName are assigned to IInvoiceView.FirstName and IInvoiceView.LastName.
When AddInvoiceLine event is raised, verify that:
a) IInvoiceView.Quantity and IInvoiceView.Amount are retrieved and assigned to InvoiceItem constructor.
b) ITaxesRepository.GetTaxesService() is called and returns ITaxesService.
c) Invoice is instantiated with ITaxesService, and InvoiceItem is added to Invoice.AddLineItem()
d) Invoice.LineItems is assigned to IInvoiceView.InvoiceLineItems property.
e) When the last expectation fails, add equality checking (IsEqual() and GetHashCode()) to InvoiceItem class, based on properties of InvoiceItem (quantity and amount.)
When CalculateTotals event is raised, verify that:
a) Invoice.SubTotal is assigned to IInvoiceView.Subtotal.
b) Invoice.TaxCalculations are assigned to IInvoiceView.TaxCalculations.
c) Invoice.Total is assigned to IInvoiceView.Total.
When SaveInvoice event is raised, verify that:
a) IInvoiceRepository.SaveInvoice() is passed the current Invoice instance.
b) When this expecation fails, add equality checking (IsEqual() and GetHashCode() to Invoice, based on 0 items equal, or equality of items.

InvoicePresenterTests.cs


[TestFixture]
public class InvoicePresenterTests
{
    private MockRepository _mockRepository;
    private ICustomerRepository _mockCustomerRepository;
    private ITaxesRepository _mockTaxesRepository;
    private IInvoiceRepository _mockInvoiceRepository;
    private IInvoiceView _mockInvoiceView;

    [SetUp]
    public void SetUp()
    {
        _mockRepository = new MockRepository();
        _mockCustomerRepository = _mockRepository.StrictMock();
        _mockTaxesRepository = _mockRepository.StrictMock();
        _mockInvoiceRepository = _mockRepository.StrictMock();
        _mockInvoiceView = _mockRepository.StrictMock();
    }

    [TearDown]
    public void TearDown()
    {
        _mockRepository.VerifyAll();
    }

    [Test]
    public void InvoicePresenterAttachesAllViewEvents()
    {
        _mockInvoiceView.GetCustomer += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.AddInvoiceLine += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.CalculateTotals += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.SaveInvoice += null;
        LastCall.IgnoreArguments();

        _mockRepository.ReplayAll();

        var invoicePresenter = new InvoicePresenter(_mockCustomerRepository, _mockTaxesRepository, _mockInvoiceRepository, _mockInvoiceView);
    }

    [Test]
    public void InvoiceGetCustomerEventRetrievesCustomerInformation()
    {
        _mockInvoiceView.GetCustomer += null;
        var getCustomerEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
        _mockInvoiceView.AddInvoiceLine += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.CalculateTotals += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.SaveInvoice += null;
        LastCall.IgnoreArguments();

        const string customerCode = "JIMSMI";
        var customer = new Customer();
        Expect.Call(_mockInvoiceView.CustomerCode).Return(customerCode);
        Expect.Call(_mockCustomerRepository.FindCustomerByCode(customerCode)).Return(customer);
        _mockInvoiceView.CustomerFirstName = customer.FirstName;
        _mockInvoiceView.CustomerLastName = customer.LastName;

        _mockRepository.ReplayAll();

        var invoicePresenter = new InvoicePresenter(_mockCustomerRepository, _mockTaxesRepository, _mockInvoiceRepository, _mockInvoiceView);
        getCustomerEventRaiser.Raise(_mockInvoiceView, EventArgs.Empty);
    }

    [Test]
    public void InvoiceAddLineItemEventAddsLineItem()
    {
        _mockInvoiceView.GetCustomer += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.AddInvoiceLine += null;
        var addInvoiceLineEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
        _mockInvoiceView.CalculateTotals += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.SaveInvoice += null;
        LastCall.IgnoreArguments();

        const int quantity = 3;
        const decimal amount = 35.00M;
        ITaxesService taxesService = new TaxesService();
        Expect.Call(_mockInvoiceView.Quantity).Return(quantity);
        Expect.Call(_mockInvoiceView.Amount).Return(amount);
        Expect.Call(_mockTaxesRepository.GetTaxesService()).Return(taxesService);
        var invoiceItem = new InvoiceItem(quantity, amount);
        var invoice = new Invoice(taxesService);
        invoice.AddLineItem(invoiceItem);
        _mockInvoiceView.InvoiceLineItems = invoice.InvoiceItems;

        _mockRepository.ReplayAll();

        var invoicePresenter = new InvoicePresenter(_mockCustomerRepository, _mockTaxesRepository, _mockInvoiceRepository, _mockInvoiceView);
        addInvoiceLineEventRaiser.Raise(_mockInvoiceView, EventArgs.Empty);
    }

    [Test]
    public void InvoiceCalculateTotalsEventDisplaysSubTotalTaxesAndTotal()
    {
        _mockInvoiceView.GetCustomer += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.AddInvoiceLine += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.CalculateTotals += null;
        var calculateTotalsEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
        _mockInvoiceView.SaveInvoice += null;
        LastCall.IgnoreArguments();

        ITaxesService taxesService = new TaxesService();
        Expect.Call(_mockTaxesRepository.GetTaxesService()).Return(taxesService);
        var invoice = new Invoice(taxesService);
        _mockInvoiceView.SubTotal = invoice.SubTotal;
        _mockInvoiceView.TaxCalculations = invoice.TaxCalculations;
        _mockInvoiceView.Total = invoice.Total;

        _mockRepository.ReplayAll();

        var invoicePresenter = new InvoicePresenter(_mockCustomerRepository, _mockTaxesRepository, _mockInvoiceRepository, _mockInvoiceView);
        calculateTotalsEventRaiser.Raise(_mockInvoiceView, EventArgs.Empty);
    }

    [Test]
    public void InvoiceSaveInvoiceToRepository()
    {
        _mockInvoiceView.GetCustomer += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.AddInvoiceLine += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.CalculateTotals += null;
        LastCall.IgnoreArguments();
        _mockInvoiceView.SaveInvoice += null;
        var saveInvoiceEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();

        ITaxesService taxesService = new TaxesService();
        Expect.Call(_mockTaxesRepository.GetTaxesService()).Return(taxesService);
        var invoice = new Invoice(taxesService);
        _mockInvoiceRepository.SaveInvoice(invoice);

        _mockRepository.ReplayAll();

        var invoicePresenter = new InvoicePresenter(_mockCustomerRepository, _mockTaxesRepository, _mockInvoiceRepository, _mockInvoiceView);
        saveInvoiceEventRaiser.Raise(_mockInvoiceView, EventArgs.Empty);
    }
}

InvoicePresenter.cs


public class InvoicePresenter
{
    private readonly ICustomerRepository _customerRepository;
    private readonly ITaxesRepository _taxesRepository;
    private readonly IInvoiceRepository _invoiceRepository;
    private readonly IInvoiceView _invoiceView;
    private Invoice _invoice;

    public InvoicePresenter(ICustomerRepository customerRepository, ITaxesRepository taxesRepository, 
                                IInvoiceRepository invoiceRepository, IInvoiceView invoiceView)
    {
        _customerRepository = customerRepository;
        _taxesRepository = taxesRepository;
        _invoiceRepository = invoiceRepository;
        _invoiceView = invoiceView;

        _invoiceView.GetCustomer += new System.EventHandler(InvoiceViewGetCustomer);
        _invoiceView.AddInvoiceLine += new System.EventHandler(InvoiceViewAddInvoiceLine);
        _invoiceView.CalculateTotals += new System.EventHandler(InvoiceViewCalculateTotals);
        _invoiceView.SaveInvoice += new System.EventHandler(InvoiceViewSaveInvoice);
    }

    void InvoiceViewSaveInvoice(object sender, System.EventArgs e)
    {
        var invoice = GetInvoice();
        _invoiceRepository.SaveInvoice(invoice);
    }

    void InvoiceViewCalculateTotals(object sender, System.EventArgs e)
    {
        var invoice = GetInvoice();
        _invoiceView.SubTotal = invoice.SubTotal;
        _invoiceView.TaxCalculations = invoice.TaxCalculations;
        _invoiceView.Total = invoice.Total;
    }

    void InvoiceViewAddInvoiceLine(object sender, System.EventArgs e)
    {
        var invoice = GetInvoice();
        invoice.AddLineItem(new InvoiceItem(_invoiceView.Quantity, _invoiceView.Amount));
        _invoiceView.InvoiceLineItems = invoice.InvoiceItems;
    }

    private Invoice GetInvoice()
    {
        if (_invoice == null)
        {
            _invoice = new Invoice(_taxesRepository.GetTaxesService());
        }
        return _invoice;
    }

    void InvoiceViewGetCustomer(object sender, System.EventArgs e)
    {
        var customer = _customerRepository.FindCustomerByCode(_invoiceView.CustomerCode);
        _invoiceView.CustomerFirstName = customer.FirstName;
        _invoiceView.CustomerLastName = customer.LastName;
    }
}

Day 4 of 5 Day TDD Kata: "AddTaxesPresenter Displays Tax Grid and Adds New Taxes"

2010-02-07T15:08:00.000-08:00

I've just completed Day 4 of the 5 Day TDD Kata.

The project is growing into multiple tests and classes, so I will only post a brief code sample below; full samples are posted to github here.

Here's the kata:

DAY 4: AddTaxesPresenter DISPLAYS TAX GRID AND ADDS NEW TAXES

Create namespaces for Presenter and View.
Create TaxesPresenterTests with mocked ITaxesService and ITaxesView.
Create ITaxesView.ShowTaxes event with default EventHandler. Verify that TaxesPresenter attaches an event handler to ShowTaxes in its constructor.
Verify that the view's ShowTaxes event, when raised, is handled by TaxesPresenter's event handler, which should assign ITaxesService.Taxes to ITaxesView.TaxesDisplay.
Create ITaxesView.AddTax event with default EventHandler. Update your first and second tests to verify that TaxPresenter's constructor now also assigns the event handler for AddTaxEvent.
Verify that when AddTax event is raised, it is handled by TaxesPresenter's event handler as follows:
a) Each required Tax constructor parameter exists as a get property of ITaxesView, and each of those properties is called (returning a value specified in the mock).
b) it creates Tax instance with the property values assigned to the mock.
c) it calls ITaxesService.AddTax() to add the Tax.
d) it refreshes ITaxesView.TaxesDisplay from ITaxesService.Taxes, which includes the just-added Tax instance.

TaxesPresenterTests.cs


[TestFixture]
public class TaxesPresenterTests
{
    private MockRepository _mockRepository;
    private ITaxesView _mockTaxesView;
    private ITaxesService _mockTaxesService;

    [SetUp]
    public void SetUp()
    {
        _mockRepository = new MockRepository();
        _mockTaxesService = _mockRepository.StrictMock();
        _mockTaxesView = _mockRepository.StrictMock();
    }

    [TearDown]
    public void TearDown()
    {
        _mockRepository.VerifyAll();
    }

    [Test]
    public void TaxesPresenterAttachesViewEventHandlersOnConstruction()
    {
        _mockTaxesView.ShowTaxes += null;
        LastCall.IgnoreArguments();
        _mockTaxesView.AddTax += null;
        LastCall.IgnoreArguments();

        _mockRepository.ReplayAll();

        var taxesPresenter = new TaxesPresenter(_mockTaxesService, _mockTaxesView);
    }

    [Test]
    public void ShowTaxesEventDisplayAllTaxes()
    {
        _mockTaxesView.ShowTaxes += null;
        var showTaxesEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
        _mockTaxesView.AddTax += null;
        LastCall.IgnoreArguments();
        var taxes = new List();
        Expect.Call(_mockTaxesService.Taxes).Return(taxes);
        _mockTaxesView.TaxesDisplay = taxes;

        _mockRepository.ReplayAll();

        var taxesPresenter = new TaxesPresenter(_mockTaxesService, _mockTaxesView);
        showTaxesEventRaiser.Raise(_mockTaxesView, EventArgs.Empty);
    }

    [Test]
    public void AddTaxEventCallsITaxesServiceAddAndReassignsToGridWithExtraRow()
    {
        _mockTaxesView.ShowTaxes += null;
        LastCall.IgnoreArguments();
        _mockTaxesView.AddTax += null;
        var addTaxEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
        const string taxType = "pstTax";
        DateTime? startDate = DateTime.Today;
        DateTime? endDate = DateTime.Today.AddYears(1);
        const JurisdictionEnum jurisdiction = JurisdictionEnum.ProvinceState;
        const int percent = 5;
        Expect.Call(_mockTaxesView.TaxType).Return(taxType);
        Expect.Call(_mockTaxesView.StartDate).Return(startDate);
        Expect.Call(_mockTaxesView.EndDate).Return(endDate);
        Expect.Call(_mockTaxesView.Jurisdiction).Return(jurisdiction);
        Expect.Call(_mockTaxesView.Percent).Return(percent);
        var tax = new Tax(taxType, startDate, endDate, jurisdiction, percent);
        _mockTaxesService.AddTax(tax);
        var taxes = new List { tax };
        Expect.Call(_mockTaxesService.Taxes).Return(taxes);
        _mockTaxesView.TaxesDisplay = taxes;

        _mockRepository.ReplayAll();

        var taxesPresenter = new TaxesPresenter(_mockTaxesService, _mockTaxesView);
        addTaxEventRaiser.Raise(_mockTaxesView, EventArgs.Empty);
    }
}

TaxesPresenter.cs


public class TaxesPresenter
{
    private readonly ITaxesService _taxesService;
    private readonly ITaxesView _taxesView;

    public TaxesPresenter(ITaxesService taxesService, ITaxesView taxesView)
    {
        _taxesService = taxesService;
        _taxesView = taxesView;

        _taxesView.ShowTaxes += new System.EventHandler(TaxesViewShowTaxes);
        _taxesView.AddTax += new System.EventHandler(TaxesViewAddTax);
    }

    void TaxesViewAddTax(object sender, System.EventArgs e)
    {
        var tax = new Tax(_taxesView.TaxType, _taxesView.StartDate, _taxesView.EndDate, _taxesView.Jurisdiction, _taxesView.Percent);
        _taxesService.AddTax(tax);
        DisplayAllTaxes();
    }

    void TaxesViewShowTaxes(object sender, System.EventArgs e)
    {
        DisplayAllTaxes();
    }

    private void DisplayAllTaxes()
    {
        _taxesView.TaxesDisplay = _taxesService.Taxes;
    }
}

Day 3 of 5 Day TDD Kata: "Invoice Applies Taxes to Items via ITaxesService"

2010-02-06T14:24:00.001-08:00

I've just completed Day 3 of the 5 Day TDD Kata.

The project is growing into multiple tests and classes, so I will only post a brief code sample below; full samples are posted to github here.

Here's the kata:

DAY 3: INVOICE APPLIES TAXES TO ITEMS VIA ITaxesService

Add new instance variable to Tax: int Percent. Add Percent to constructor. Include percent in instance equality. Fix all tests. Add test to reject 0 percent as constructor parameter.
Create InvoiceTests class.
In Setup, create ITaxesService stub with taxes from 3 jurisdictions.
Inject ITaxesService into Invoice constructor. Validate that Invoice.Taxes equals ITaxesService.Taxes.
Create InvoiceItemTests. Verify that InvoiceItem is constructed with quantity and amount parameters, values shoudl match properties InvoiceItem.Quantity and InvoiceItem.Amount. (Product and/or Description are outside scope of this kata.)
Submitting 0 to quantity or amount throws exception, but object equality is not required.
Return to InvoiceTests. Validate that when Invoice adds InvoiceItems, that TotalItemQuantity matches sum of Items quantity.
Invoice SubTotal matches sum of (Quantity * Amount)
Invoice has multiple TaxCalculations, each has Tax and Amount properties. Validate that each TaxCalculation.Amount = SubTotal * Tax.Percent / 100 (eg. 20.00 * 5 * .01 = 1.00).
Invoice Total matches Invoice.SubTotal + sum of (Invoice.TaxCalculations).

InvoiceItemTests.cs


[TestFixture]
public class InvoiceItemTests
{
    [Test]
    public void InvoiceItemParametersMatchProperties()
    {
        const int quantity = 3;
        const decimal amount = 15.25M;
        var invoiceLineItem = new InvoiceItem(quantity, amount);

        Assert.AreEqual(quantity, invoiceLineItem.Quantity);
        Assert.AreEqual(amount, invoiceLineItem.Amount);
    }

    [Test]
    [ExpectedException(typeof(NullOrZeroConstructorParameterException))]
    public void InvoiceItemRequiresNonZeroQuantittOnCreation()
    {
        const int quantity = 0;
        const decimal amount = 15.25M;
        var invoiceLineItem = new InvoiceItem(quantity, amount);
    }

    [Test]
    [ExpectedException(typeof(NullOrZeroConstructorParameterException))]
    public void InvoiceItemRequiresNonZeroAmountOnCreation()
    {
        const int quantity = 4;
        const decimal amount = 0M;
        var invoiceLineItem = new InvoiceItem(quantity, amount);
    }

}

InvoiceTests.cs


[TestFixture]
public class InvoiceTests
{
    private MockRepository _mockRepository;
    private ITaxesService _mockTaxesService;
    private City _city;
    private ProvinceState _provinceState;
    private Country _country;

    [SetUp]
    public void Setup()
    {
        _mockRepository = new MockRepository();
        _mockTaxesService = _mockRepository.Stub();

        _city = new City("CityTax", _mockTaxesService);
        var cityTax = new Tax("CityTax", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.City, 2);
        _mockTaxesService.Taxes.Add(cityTax);

        _provinceState = new ProvinceState("ProvStateTax", _mockTaxesService);
        var provStateTax = new Tax("ProvStateTax", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.ProvinceState, 3);
        _mockTaxesService.Taxes.Add(provStateTax);

        _country = new Country("CountryTax", _mockTaxesService);
        var countryTax = new Tax("CountryTax", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.Country, 4);
        _mockTaxesService.Taxes.Add(countryTax);
    }

    [Test]
    public void InvoiceGetsTaxesFromITaxesService()
    {
        var invoice = new Invoice(_mockTaxesService);
        Assert.AreEqual(invoice.Taxes, _mockTaxesService.Taxes);
    }

    [Test]
    public void InvoiceSumOfInvoiceLineItemQtyMatchesTotalItemQuantity()
    {
        var invoice = GetInvoice();

        Assert.AreEqual(12, invoice.TotalItemQuantity);
    }

    [Test]
    public void InvoiceSubtotalEqualsSumOfItemQuantityTimesAmount()
    {
        var invoice = GetInvoice();

        Assert.AreEqual(95.00M, invoice.SubTotal);
    }

    [Test]
    public void InvoiceHasMultipleTaxCalcRowsWithTypeAndTaxAmount()
    {
        var invoice = GetInvoice();

        foreach (var taxCalculation in invoice.TaxCalculations)
        {
            var expectedAmount = invoice.SubTotal * taxCalculation.Tax.Percent * .01M;

             switch (taxCalculation.Tax.Jurisdiction)
            {
                case JurisdictionEnum.City:
                    Assert.AreEqual(expectedAmount, taxCalculation.Amount);
                    break;
                case JurisdictionEnum.ProvinceState:
                    Assert.AreEqual(expectedAmount, taxCalculation.Amount);
                    break;
                case JurisdictionEnum.Country:
                    Assert.AreEqual(expectedAmount, taxCalculation.Amount);
                    break;
            }
        }
    }

    [Test]
    public void InvoiceTotalIsSubTotalPlusSumOfTaxCalculations()
    {
        var invoice = GetInvoice();

        var expectedAmount = invoice.SubTotal;

        foreach (var taxCalculation in invoice.TaxCalculations)
            expectedAmount += taxCalculation.Amount;

        Assert.AreEqual(expectedAmount, invoice.Total);
    }

    private Invoice GetInvoice()
    {
        var invoice = new Invoice(_mockTaxesService);
        invoice.AddLineItem(new InvoiceItem(3, 15.00M));
        invoice.AddLineItem(new InvoiceItem(4, 10.00M));
        invoice.AddLineItem(new InvoiceItem(5, 2.00M));
        return invoice;
    }

}

Day 2 of 5 Day TDD Kata: "City Tax Validation is Teased Out into new ITaxesService"

2010-02-05T09:26:00.000-08:00

I've just completed Day 2 of the 5 Day TDD Kata.

The project is growing into multiple tests and classes, so I will only post a brief code sample below; full samples are posted to github here.

Here's the kata:

DAY 2: TEASING OUT DOMAIN OBJECT: ITaxesService

Create JurisdictionEnum { City, State, Country }
Alter TaxesTest test methods to now test for Jurisdiction as required 4th Tax property.
Add new constructor parameter to City: ITaxesService, so that City constructor calls in CityTests will no longer compile.
Comment out ALL public and private methods in City, so that the Add(Tax tax) method call in CityTests will no longer compile.
Since the tests no longer compile, comment out all test methods in the CityTests class.
Reference a mocking framework and add a using statement to CityTests class.
Create new test in CityTests which verifies that when City is asked to AddTax(), that it delegates tax adding to the mocked ITaxesService. City should be agnostic to tax storage.
Create new test in ProvinceTests which verifies that when Province is asked to AddTax(), that it delegates tax adding to the mocked ITaxesService. Province should be agnostic to tax storage.
Create new test in CountryTests which verifies that when Country is asked to AddTax(), that it delegates tax adding to the mocked ITaxesService. Country should be agnostic to tax storage.
Create a TaxesServiceTests class.
Move the commented-out CityTest methods to TaxesServiceTests class and repurpose them to address the TaxesService.Add() method and Taxes property.
Notes: When creating TaxesService, make it implement ITaxesService, and use a parameterless constructor. Remember to move the commented out public and private methods from City class to the new TaxesService class--you'll need them for the tests to pass.
Validate that tax duplication checking logic now constrains on BOTH TaxType AND Jurisdiction.
For extra points: Create a test which instantiates City, Province, and Country, injecting each with a common stub of ITaxesService and adding a tax from each jurisdiction. Validate that 3 taxes have been added to ITaxesService stub. Also validate that each class' Taxes collection returns only taxes for that jurisdiction.

CityTests.cs


[TestFixture]
public class CityTests
{
    private MockRepository _mockRepository;
    private ITaxesService _mockTaxesService;

    [SetUp]
    public void SetUp()
    {
        _mockRepository = new MockRepository();
        _mockTaxesService = _mockRepository.StrictMock();
    }

    [TearDown]
    public void TearDown()
    {
        _mockRepository.ReplayAll();
        _mockRepository.VerifyAll();
    }

    [Test]
    public void CityDelegatesAddedTaxesToInjectedTaxesService()
    {
        // expectations
        var pstTax = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.City);
        _mockTaxesService.AddTax(pstTax);

        _mockRepository.ReplayAll();

        var city = new City("Winnipeg", _mockTaxesService);
        city.AddTax(pstTax);            
    }
}

TaxesServiceTests.cs


[TestFixture]
public class TaxesServiceTests
{
    [Test]
    public void TaxesServiceCanAccumulateTaxes()
    {
        var taxesService = new TaxesService();
        var pstTax = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.City);
        taxesService.AddTax(pstTax);

        Assert.IsTrue(taxesService.Taxes.Contains(pstTax));
    }

    [Test]
    [ExpectedException(typeof(DuplicateTaxesException))]
    public void TaxesServiceRejectsDuplicateTaxes()
    {
        var taxesService = new TaxesService();
        var pstTax1 = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.City);
        var pstTax2 = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.City);
        taxesService.AddTax(pstTax1);
        taxesService.AddTax(pstTax2);
    }

    [Test]
    [ExpectedException(typeof(OverlappingTaxTypesException))]
    public void TaxesServiceRejectsOverlappingTaxesPerTaxType()
    {
        var taxesService = new TaxesService();
        var pstTax1 = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6), JurisdictionEnum.City);
        var pstTax2 = new Tax("PST", DateTime.Today.AddMonths(6), DateTime.Today.AddYears(1), JurisdictionEnum.City);
        taxesService.AddTax(pstTax1);
        taxesService.AddTax(pstTax2);
    }
}

Day 1 of 5 Day TDD Kata: "Taxes Are Validated As They Are Added to City"

2010-02-04T09:24:00.000-08:00

I've just completed Day 1 of the 5 Day TDD kata in about 40 minutes:

Samples posted to github here.

DAY 1: TAXES ARE VALIDATED AS THEY ARE ADDED TO CITY

Tax must be created with its 3 properties: TaxType, StartDate, and EndDate, none of which can be null.
StartDate must be less than EndDate
Equality is based on the 3 properties together
City has Taxes.
City rejects duplicate Taxes (by object equality.)
City rejects overlapping taxes (EndDate > other tax start date) for a given TaxType.

To achieve this:

I first created tests for Tax, which validated that it was fed all properties from the constructor, did not allow nulls, based object equality on all 3 properties, and did not allow EndDate earlier than StartDate.

I then created tests for City, which added tax objects to Taxes collection, rejected duplicates, and rejected overlapping EndDates with StartDate by tax type.

Tests and classes below.

TaxTests.cs


[TestFixture]
public class TaxTests
{
    [Test]
    [ExpectedException(typeof(TaxValuesMissingException))]
    public void TaxCannotBeCreatedWithAllNullProperties()
    {
        var tax = new Tax(null, null, null);
    }

    [Test]
    [ExpectedException(typeof(TaxValuesMissingException))]
    public void TaxCannotBeCreatedWithNullTaxType()
    {
        var tax = new Tax(null, DateTime.Today.AddDays(1), DateTime.Today.AddYears(1));
    }

    [Test]
    [ExpectedException(typeof(TaxValuesMissingException))]
    public void TaxCannotBeCreatedWithNullStartDate()
    {
        var tax = new Tax("PST", null, DateTime.Today.AddYears(1));
    }

    [Test]
    [ExpectedException(typeof(TaxValuesMissingException))]
    public void TaxCannotBeCreatedWithNullEndDate()
    {
        var tax = new Tax("PST", DateTime.Today.AddDays(1), null);
    }

    [Test]
    public void TaxCanBeCreatedWhenAllPropertiesSupplied()
    {
        var tax = new Tax("PST", DateTime.Today.AddDays(1), DateTime.Today.AddYears(1));
        Assert.IsNotNull(tax);
    }

    [Test]
    [ExpectedException(typeof(InvalidTaxDateRangeException))]
    public void TaxStartDateCannotBeGreaterThanEndDate()
    {
        var tax = new Tax("PST", DateTime.Today.AddYears(1).AddDays(1), DateTime.Today.AddYears(1));
        Assert.IsNotNull(tax);
    }

    [Test]
    public void TaxesAreEqualWhenConstructorParametersMatch()
    {
        var tax1 = new Tax("PST", DateTime.Today.AddDays(1), DateTime.Today.AddYears(1));
        var tax2 = new Tax("PST", DateTime.Today.AddDays(1), DateTime.Today.AddYears(1));

        Assert.IsTrue(tax1.Equals(tax2));
        // Assert.AreSame(tax1, tax2) failed, may be referencing another nunit namespace??
    }
}

Tax.cs


public class Tax
{
    private readonly string _taxType;
    private readonly DateTime? _startDate;
    private readonly DateTime? _endDate;

    private Tax()
    {
    }

    public Tax(string taxType, DateTime? startDate, DateTime? endDate)
    {
        _taxType = taxType;
        _startDate = startDate;
        _endDate = endDate;

        ValidateAllParametersHaveNonNullValue();

        ValidateEndDateGreaterThanStartDate();
    }

    public string TaxType
    {
        get { return _taxType; }
    }

    public DateTime? StartDate
    {
        get { return _startDate; }
    }

    public DateTime? EndDate
    {
        get { return _endDate; }
    }

    public override bool Equals(object obj)
    {
        var otherTax = (Tax) obj;

        var isEqual = otherTax.TaxType.Equals(this.TaxType)
               && otherTax.StartDate.Value.Equals(this.StartDate.Value)
               && otherTax.EndDate.Value.Equals(this.EndDate.Value);

        return isEqual;
    }

    public override int GetHashCode()
    {
        return StartDate.GetHashCode() + EndDate.GetHashCode() + TaxType.GetHashCode();
    }

    private void ValidateEndDateGreaterThanStartDate()
    {
        if (StartDate.Value > EndDate.Value)
            throw new InvalidTaxDateRangeException();
    }

    private void ValidateAllParametersHaveNonNullValue()
    {
        if (TaxType == null
            || !StartDate.HasValue
            || !EndDate.HasValue)
            throw new TaxValuesMissingException();
    }
}

CityTests.cs


[TestFixture]
public class CityTests
{
    [Test]
    public void CityCanAddTaxes()
    {
        var city = new City("Winnipeg");
        var pstTax = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6));
        city.AddTax(pstTax);

        Assert.IsTrue(city.Taxes.Contains(pstTax));
    }

    [Test]
    [ExpectedException(typeof(DuplicateTaxesException))]
    public void CityRejectsDuplicateTaxes()
    {
        var city = new City("Winnipeg");
        var pstTax1 = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6));
        var pstTax2 = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6));
        city.AddTax(pstTax1);
        city.AddTax(pstTax2);
    }

    [Test]
    [ExpectedException(typeof(OverlappingTaxTypesException))]
    public void CityRejectsOverlappingTaxesPerTaxType()
    {
        var city = new City("Winnipeg");
        var pstTax1 = new Tax("PST", DateTime.Today, DateTime.Today.AddMonths(6));
        var pstTax2 = new Tax("PST", DateTime.Today.AddMonths(6), DateTime.Today.AddYears(1));
        city.AddTax(pstTax1);
        city.AddTax(pstTax2);
    }

}

City.cs


public class City
{
    private readonly string _name;

    public City(string name)
    {
        _name = name;
        Taxes = new List();
    }

    public List Taxes { get; private set; }

    public void AddTax(Tax tax)
    {
        if (tax == null) throw new ArgumentNullException("tax");
        RejectDuplicateTaxes(tax);
        RejectOverlappingTaxes(tax);

        this.Taxes.Add(tax);
    }

    private void RejectOverlappingTaxes(Tax tax)
    {
        foreach(var currowTax in this.Taxes)
        {
            if(IsFutureTax(tax, currowTax)
               && FutureTaxOverlapsEndDateOfCurrowTax(tax, currowTax))
                throw new OverlappingTaxTypesException();

            if(IsEarlierTax(tax, currowTax)
                && CurrowTaxOverlapsEndDateOfPreviousTax(tax, currowTax))
                throw new OverlappingTaxTypesException();
        }
    }

    private static bool CurrowTaxOverlapsEndDateOfPreviousTax(Tax tax, Tax currowTax)
    {
        return currowTax.TaxType.Equals(tax.TaxType)
                && currowTax.StartDate <= tax.EndDate;     }      private static bool IsEarlierTax(Tax tax, Tax currowTax)     {         return currowTax.TaxType.Equals(tax.TaxType)                 && tax.StartDate.Value < currowTax.StartDate;     }      private static bool FutureTaxOverlapsEndDateOfCurrowTax(Tax tax, Tax currowTax)     {         return currowTax.TaxType.Equals(tax.TaxType)                 && tax.StartDate <= currowTax.EndDate;     }      private static bool IsFutureTax(Tax tax, Tax currowTax)     {         return currowTax.TaxType.Equals(tax.TaxType)                 && tax.StartDate.Value > currowTax.StartDate;
    }

    private void RejectDuplicateTaxes(Tax tax)
    {
        if(this.Taxes.Contains(tax))
            throw new DuplicateTaxesException();
    }
}

5 Day TDD Kata

2010-02-03T21:46:00.000-08:00

From Single Class, to Teasing Out Domain, to Model-View-Presenter with Mocks

Samples are posted to github here.

While the Calculator kata has been tremendously beneficial, I am wanting to experiment with a larger TDD kata that attempts test coverage at 3 levels:

For a single class.
For teasing out 1 or more objects in the domain.
For testing presenter with mocks, in Model-View-Presenter, using the newly-created domain.

Below is the initial outline. Over the next 5 days I will do the kata, and adjust the instructions for each day as the design becomes clearer.

Summary
DAY 1: TAXES ARE VALIDATED AS THEY ARE ADDED TO CITY
DAY 2: TEASING OUT DOMAIN OBJECT: ITaxesService
DAY 3: INVOICE APPLIES TAXES TO ITEMS VIA ITaxesService
DAY 4: AddTaxesPresenter DISPLAYS TAX GRID AND ADDS NEW TAXES
DAY 5: InvoicePresenter ADDS AND DISPLAYS INVOICE WITH TAXES AND TOTALS

Detail
DAY 1: TAXES ARE VALIDATED AS THEY ARE ADDED TO CITY

Tax must be created with its 3 properties: TaxType, StartDate, and EndDate, none of which can be null.
StartDate must be less than EndDate
Equality is based on the 3 properties together
City has Taxes.
City rejects duplicate Taxes (by object equality.)
City rejects overlapping taxes (EndDate > other tax start date) for a given TaxType.

DAY 2: TEASING OUT DOMAIN OBJECT: ITaxesService

Create JurisdictionEnum { City, State, Country }
Alter TaxesTest test methods to now test for Jurisdiction as required 4th Tax property.
Add new constructor parameter to City: ITaxesService, so that City constructor calls in CityTests will no longer compile.
Comment out ALL public and private methods in City, so that the Add(Tax tax) method call in CityTests will no longer compile.
Since the tests no longer compile, comment out all test methods in the CityTests class.
Reference a mocking framework and add a using statement to CityTests class.
Create new test in CityTests which verifies that when City is asked to AddTax(), that it delegates tax adding to the mocked ITaxesService. City should be agnostic to tax storage.
Create new test in ProvinceTests which verifies that when Province is asked to AddTax(), that it delegates tax adding to the mocked ITaxesService. Province should be agnostic to tax storage.
Create new test in CountryTests which verifies that when Country is asked to AddTax(), that it delegates tax adding to the mocked ITaxesService. Country should be agnostic to tax storage.
Create a TaxesServiceTests class.
Move the commented-out CityTest methods to TaxesServiceTests class and repurpose them to address the TaxesService.Add() method and Taxes property.
Notes: When creating TaxesService, make it implement ITaxesService, and use a parameterless constructor. Remember to move the commented out public and private methods from City class to the new TaxesService class--you'll need them for the tests to pass.
Validate that tax duplication checking logic now constrains on BOTH TaxType AND Jurisdiction.
For extra points: Create a test which instantiates City, Province, and Country, injecting each with a common stub of ITaxesService and adding a tax from each jurisdiction. Validate that 3 taxes have been added to ITaxesService stub. Also validate that each class' Taxes collection returns only taxes for that jurisdiction.

DAY 3: INVOICE APPLIES TAXES TO ITEMS VIA ITaxesService

Add new instance variable to Tax: int Percent. Add Percent to constructor. Include percent in instance equality. Fix all tests. Add test to reject 0 percent as constructor parameter.
Create InvoiceTests class.
In Setup, create ITaxesService stub with taxes from 3 jurisdictions.
Inject ITaxesService into Invoice constructor. Validate that Invoice.Taxes equals ITaxesService.Taxes.
Create InvoiceItemTests. Verify that InvoiceItem is constructed with quantity and amount parameters, values shoudl match properties InvoiceItem.Quantity and InvoiceItem.Amount. (Product and/or Description are outside scope of this kata.)
Submitting 0 to quantity or amount throws exception, but object equality is not required.
Return to InvoiceTests. Validate that when Invoice adds InvoiceItems, that TotalItemQuantity matches sum of Items quantity.
Invoice SubTotal matches sum of (Quantity * Amount)
Invoice has multiple TaxCalculations, each has Tax and Amount properties. Validate that each TaxCalculation.Amount = SubTotal * Tax.Percent / 100 (eg. 20.00 * 5 * .01 = 1.00).
Invoice Total matches Invoice.SubTotal + sum of (Invoice.TaxCalculations).

DAY 4: AddTaxesPresenter DISPLAYS TAX GRID AND ADDS NEW TAXES

Create namespaces for Presenter and View.
Create TaxesPresenterTests with mocked ITaxesService and ITaxesView.
Create ITaxesView.ShowTaxes event with default EventHandler. Verify that TaxesPresenter attaches an event handler to ShowTaxes in its constructor.
Verify that the view's ShowTaxes event, when raised, is handled by TaxesPresenter's event handler, which should assign ITaxesService.Taxes to ITaxesView.TaxesDisplay.
Create ITaxesView.AddTax event with default EventHandler. Update your first and second tests to verify that TaxPresenter's constructor now also assigns the event handler for AddTaxEvent.
Verify that when AddTax event is raised, it is handled by TaxesPresenter's event handler as follows:
a) Each required Tax constructor parameter exists as a get property of ITaxesView, and each of those properties is called (returning a value specified in the mock).
b) it creates Tax instance with the property values assigned to the mock.
c) it calls ITaxesService.AddTax() to add the Tax.
d) it refreshes ITaxesView.TaxesDisplay from ITaxesService.Taxes, which includes the just-added Tax instance.

DAY 5: InvoicePresenter ADDS AND DISPLAYS INVOICE WITH TAXES AND TOTALS

The culmination. This kata works with everything you have built leading up to it.

Create a namespace for Repository.
Create CustomerTests. Verify when Customer adds an Invoice, that Customer.Invoices increments.
Create InvoicePresenterTests with 4 mocked interfaces: ITaxesRepository, ICustomerRepository, IInvoiceRepository, and IInvoiceView.
Create the following IInvoiceView events, each with a default EventHandler:
- GetCustomer event
- AddInvoiceLine event
- CalculateTotals event
- SaveInvoice event
For each one, verify that InvoicePresenter's constructor attaches that event to an event handler. (You can expect each event to be assigned to null, and instruct the mock to ignore the argument. For subsequent tests, you only need to get the event if the current test needs to verify behaviour that occurs when the event is raised.)
When GetCustomer event is raised, verify that
a) IInvoiceView.CustomerCode is assigned to ICustomerRepository.FindCustomerByCode().
b) the returned Customer is retrieved, and FirstName and LastName are assigned to IInvoiceView.FirstName and IInvoiceView.LastName.
When AddInvoiceLine event is raised, verify that:
a) IInvoiceView.Quantity and IInvoiceView.Amount are retrieved and assigned to InvoiceItem constructor.
b) ITaxesRepository.GetTaxesService() is called and returns ITaxesService.
c) Invoice is instantiated with ITaxesService, and InvoiceItem is added to Invoice.AddLineItem()
d) Invoice.LineItems is assigned to IInvoiceView.InvoiceLineItems property.
e) When the last expectation fails, add equality checking (IsEqual() and GetHashCode()) to InvoiceItem class, based on properties of InvoiceItem (quantity and amount.)
When CalculateTotals event is raised, verify that:
a) Invoice.SubTotal is assigned to IInvoiceView.Subtotal.
b) Invoice.TaxCalculations are assigned to IInvoiceView.TaxCalculations.
c) Invoice.Total is assigned to IInvoiceView.Total.
When SaveInvoice event is raised, verify that:
a) IInvoiceRepository.SaveInvoice() is passed the current Invoice instance.
b) When this expecation fails, add equality checking (IsEqual() and GetHashCode() to Invoice, based on 0 items equal, or equality of items.

Congratulations! You have now completed the 5 Day TDD kata!

A reminder: samples are posted to github here.

Evolution of test coverage

2010-01-30T10:48:00.000-08:00

One of the projects I've worked on over the last couple of years has been benefitting from ever-increasing test coverage. The data layer was originally written using DataSets, but awhile back was moved to a domain model with NHibernate as the ORM. The domain model adheres quite closely to the database ERM (one class per table). A unit testing layer has been built along with the domain model. The unit testing layer has been growing/evolving as new business requirements have been added to the project.

The tests have adhered closer to a "test-last" or "test-middle" model than a "test-first" model, since initial tests were built immediately after migration of the domain model:

First, the domain model was created, with entity classes mapped closely to the underlying database tables
Second, the original business logic was migrated across, which in effect redistributed it from Transaction Script pattern to Domain Model pattern.
Finally, an initial set of unit tests were built against the classes of the domain model.

Since then, unit tests have been built at two levels of scope, corresponding roughly to two different points of entry on a sequence diagram. In the domain model, the sequence diagram would begin with a higher-level entity, and then drill down into (and come back up from) lower-level objects in the domain. Therefore:

If a unit test is addressing an individual entity method farther to the right in the sequence diagram, it will be small and focused exclusively on verification of the behaviour of that method.
If a unit test is addressing a method at the far left of the sequence diagram (a point-of-entry), the test will tend to be much larger, begin with a large stub, and then verify multiple points within an object graph at the end of the test. These larger tests tend to be grouped, with each version of the test checking a different scenario from a matrix diagram.

In the current project, the combination of the above tests has evolved to 300+ tests, and this has provided an invaluable safety net to more easily make changes to the domain model in response to ongoing business requirements.

So, does this imply that QA no longer has any work to do? No, but the issues that are found by QA now tend to concentrate elsewhere, either in:
1) Newly discovered business logic that differs from the understanding currently reflected in the domain tests (resulting in 95% domain coverage rather than 100% domain coverage.)
2) Layers ABOVE the domain model layer that are more difficult to test, including:
     a) Repository (database query) layer: missing query information
     b) Service layer: incorrect coordination of calls to repository and domain tiers
     c) Remote facade/web service layer: missing elements or nulls when mapping to/from web service DTOs or DataSets

Integration tests do exist for testing a complete process, including database interactions and the service layer, but these tend to be tied to specific data and require some amount of setup, often involving cooperation from QA.

On a couple of previous projects, I have had some success with greater automated test coverage across all layers, but this required use of a database sandbox: rather that working with a copy of production data (which tends to be large, constantly evolving, and therefore poor for testing multiple integration scenarios) instead build an entire database from a script, which can then be dropped/recreated before each run of the automated tests, populating the sandbox with only the subset of data required for the integration tests.

Conclusion

The ultimate goal for test coverage is to be as complete as possible, covering every layer, not just the domain model, but all levels above it, up to and including the client.

The Vetrinary Admin: Linking TDD Kata to creating user stories

2010-01-27T13:06:00.000-08:00

Today is my 12th day of doing the TDD kata experiment. Mostly it has been with the Calculator kata, but I've started experimenting with creating new katas. First was a Model-View-Presenter kata with mocks, but I am now taking this one step further.

What the TDD kata makes obvious is the practise of writing tests based on a user story.

Historically I am more accustomed to working from a detailed requirements spec, which the last few years has tended to look like this:

1) Read the spec
2) Create a domain model and NHibernate mappings, to database tables which typically were created previously (legacy code or a previous phase).
3) Figure out how the spec translates into distribution across the domain model objects.
4) Write unit tests for various domain model methods as you create them

Not fully test first, more like test middle. And the domain model tends to be mapped fairly closely to the database tables, so the domain entities tend to grow.

But that's a discussion for a whole other blog post. My purpose here is let the TDD kata approach (getting direction from a user story) be my opportunity to practice creating tests directly from user stories.

I've started reading User Stories Applied by Mike Cohn, and I've decided to try some experiments with TDD kata by creating a list of user stories (eg. for a vetrinarian administrator), choosing one of the user stories to write out, and then building a TDD kata based on that story.

Here is today's example, for the vetrinarian administrator:

5 User Stories
#1 - Vet admin can enter pet details (register the pet)
#2 - Vet admin can log a single pet visit
#3 - Vet admin can track and add medications for a pet
#4 - Vet admin can create an invoice for the visit
#5 - Vet admin can create a purchase order for specialized pet foods

[Edit - adding more user story details]
#1 Vet admin can enter pet details (register the pet)
a) Can enter pet with name, breed, age, temperment, and brief health history.
b) Can enter owner name and address (if new).
c) Can associate the owner to the pet (add to owner's list of pets)

#2 Vet admin can log a single pet visit
a) Vet admin can create a pet visit record.
b) Vet admin can enter the comments provided by the vet about the visit
c) Vet admin can add a list of new prescriptions to the pet's prescription list, and link them to this visit.
d) Vet admin can issue a receipt for payment.
[end Edit.]

If I take the 3rd user story, I then write it out in detail:

#3 Vet admin can track pet medications
a) Vet admin can search for medications by name
b) Vet can assign found medication to Fluffy the dog's record
c) If Fluffy has allergy to the newly assigned medication, a flag will be raised
d) If new medication has contraindications with Fluffy's existing meds, a flag will be raised.
e) If flag is raised, vet admin must get Vet override before adding
f) Vet admin can enter prescription date, dosage instructions
g) Vet admin can print prescription.

Now, obviously this user story is too big for a 30 minute TDD kata, but it's a place for me to get started. My hope was that I could just address the domain in my kata, but the user story already includes a medication lookup, which is probably a repository query, so I decided to build the tests at the Model-View-Presenter level with mocked repository and view.

In 30 minutes, I managed to complete only the first step:


[TestFixture]
public class MedicationTrackerPresenterTests
{
private MockRepository _mockRepository;
private IMedicationTrackerView _medicationTrackerView;
private IMedicationRepository _medicationRepository;

[SetUp]
public void SetUp()
{
_mockRepository = new MockRepository();
_medicationTrackerView = _mockRepository.StrictMock();
_medicationRepository = _mockRepository.StrictMock();
}

[TearDown]
public void TearDown()
{
_mockRepository.ReplayAll();
_mockRepository.VerifyAll();
}

[Test]
public void VetAdminCanSearchForMedicationsByName()
{
_medicationTrackerView.SearchEvents += null;
var searchMedicationsEventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
const string searchInput = "Tylenol";
var medications = new List();
Expect.Call(_medicationTrackerView.SearchInput).Return(searchInput).IgnoreArguments();
Expect.Call(_medicationRepository.FindMedicationsByName(searchInput)).Return(medications);
_medicationTrackerView.MedicationsSearchResult = medications;

_mockRepository.ReplayAll();

var medicationTrackerPresenter = new MedicationTrackerPresenter(_medicationRepository, _medicationTrackerView);
searchMedicationsEventRaiser.Raise(_medicationTrackerView, EventArgs.Empty);
}
}

Tomorrow, I will go back to Calculator kata (every 2nd day at least). But this process of going from application concept, to a list of user stories, to fleshing out 1 user story, to building the tests for that story as a TDD kata, feels like a strong practise that I want to reinforce.

Upgraded version of #goos C# sample code ch.14 posted with "WinFormLicker"

2010-01-24T17:17:00.000-08:00

I have just posted an update of the #goos (Growing Object-Oriented Software, Guided by Tests) C# sample code for chapter 14. This version now adheres more closely to the Java sample code by providing classes in a "WinFormLicker" namespace that launch a WinForm instance in a separate thread and to observe the actions applied against the controls, similar to the behaviour applied to the Swing JFrame window in the Java sample code.

The code is posted here:

http://github.com/dgadd/GOOS_sample_csharp

Creating a C# Window Inspector to parallel WindowLicker in the Java #goos sample code (updated)

2010-01-23T11:56:00.000-08:00

This morning, I started into chapter 15 of Growing Object-Oriented Software, Guided by Tests. At this point, reliance on WindowLicker in the Java code to inspect the changes happening in the GUI layer is increasing. I had been avoiding this by simply using a mock IAuctionSniperView interface, and validating that the interface's Status string property had been set.

However, this creates a few problems:
1) The C# code isn't fully parallel to the Java sample code
2) In the book, the end-to-end/acceptance tests operate at single level of scope, calling either ApplicationRunner or FakeAuctionServer to validate each step of the test. By using a mocked interface, I had to place the mock expected actions (replay and verify) at the top level (rather than inside AppicationRunner).
3) And, of course, it's not truly an end-to-end test, as it stops at the view interface.

I decided to experiment with writing some tests in a new project to see what the minimal amount of code would be necessary to create a simple WinForm inspector that could start simply by observing the activity of the status Label being set.

After a few false starts (and needing to review my knowledge of the ParmeterizedThreadStart class) I managed to get this working and displaying a label.

The tests:


[TestFixture]
public class WinFormInspectorTests
{
private WinFormInspector _winFormInspector;

[SetUp]
public void Setup()
{
_winFormInspector = new WinFormInspector(new Main());          
}

[Test]
public void Inspector_Can_Instantiate_WinForm()
{
Assert.IsNotNull(_winFormInspector.Main);
}

[Test]
public void Inspector_Can_Launch_Application()
{
_winFormInspector.LaunchApplication();
_winFormInspector.SleepApplication(1000);
_winFormInspector.QuitApplication();
}

[Test]
public void Inspector_Can_Observe_Status_Label()
{
const string status = "Lost";

_winFormInspector.LaunchApplication();
_winFormInspector.Main.SniperStatus = status;
_winFormInspector.ShowsSniperStatus(status);
_winFormInspector.SleepApplication(1000);
_winFormInspector.QuitApplication();
}
}

The WinFormInspector class:


public class WinFormInspector
{
private readonly Main _main;
private Thread _thread;


public WinFormInspector(Main main)
{
_main = main;
}

public Main Main
{
get { return _main; }
}

public void ShowsSniperStatus(string expectedStatus)
{
if (!_main.SniperStatus.Equals(expectedStatus))
{
throw new Exception("Expected status does not match SniperStatus label.");
}
}

public void LaunchApplication()
{
_thread = new Thread(new ParameterizedThreadStart(Launch));
_thread.Start(this.Main);
}

public void SleepApplication(int sleepMilliseconds)
{
Thread.Sleep(sleepMilliseconds);
}

public void QuitApplication()
{
this.Main.Close();
Application.Exit();
}

private static void Launch(object input)
{
var form = (Form)input;
Application.Run(form);
}
}

...and the WinForm class, "Main":


public class Main : Form
{
private readonly Label _lblStatus;

public Main()
{
_lblStatus = new Label();
this.Controls.Add(_lblStatus);
}

public string SniperStatus
{
get
{
return _lblStatus.Text;
}
set
{
_lblStatus.Text = value;
}
}
}

My next step is to move this over into the AuctionSniper C# sample code project. One of the things I'm debating is whether to keep the mocked view tests as well.

Eclipse / Visual Studio keyboard shortcuts for TDD Calculator kata

2010-01-22T18:52:00.000-08:00

Tonight I tried out the TDD Calculator kata in Eclipse.

As part of the process, I searched for equivalent keyboard shortcuts in Eclipse, and came up with the following quick comparison:

Eclipse	Visual Studio with Resharper	Task
Ctrl-F6	Ctrl-Tab	Jump between Classes
Ctrl-F7	Ctrl-Tab-LeftArrow	Jump between Views
Alt-Shift-Q,P	Ctrl-Alt-L	Jump to Package / Solution Explorer
Ctrl-Shift-W	Alt-W,L	Close All Editor Windows
Ctrl-Shift-F8	F5	Go to Debug (Switch Perspectives)
Alt-Shift-X, T	Ctrl-R-A(VS) Option-R-U-N(R#)	Run All Tests
Alt-Shift-D, T	Ctrl-R,Ctrl-T(VS) Option-R-U-D(R#)	Run Contextual Test in Debug Mode
F2	Alt-Enter OR Alt-Shift-F10	Show refactoring suggestions
Alt-Shift-M	Ctrl-R-M	Extract Method
Alt-Shift-V	Ctrl-R-O	Move Class to another Namespace
Ctrl-7 (toggle)	Ctrl-K-C	Comment a block of code
Ctrl-7 (toggle)	Ctrl-K-U	Uncomment a block of code

TDD Calculator kata: thoughts on day 6

2010-01-21T21:22:00.000-08:00

I've been doing the TDD Calculator kata (as per Roy Osherove: http://osherove.com/tdd-kata-1/) the last 6 days. Today was the first day where I did the complete kata. I got the first section down to 22 minutes, but by the time I tackled the final issue (recognizing and processing multiple custom delimiters) the frustration had kicked in and I had metaphorically rolled up my sleeves: staring at output in debug mode, watching side-effects break 4 of the previous tests, and feeling stress levels go up as the clock ticked. I finally resolved all issues, had all tests passing, and did final refactoring in just under 45 minutes.

Temporary stress levels aside, this has been a very productive experience. I've seen a number of patterns emerging with each successive repetition of the practise:

1) Faster and faster interaction with Resharper
I have had friends recommending Resharper to me for a couple of years now, but it was actually working with Eclipse & Java again to build the sample code in "Growing Object-Oriented Software, Guided by Tests" that reminded me about all the tools that Eclipse provides to assist with code generation as you build test-first. When I returned to Visual Studio to build the equivalent code in C#, it quickly became apparent that Resharper was the Eclipse-ification of Visual Studio. With the beginning of the TDD kata practise, the usage of Resharper has become even more prominent, with reliance on it for class and interface geneation, constant reference to its recommendations for improving the code, and quick in-browser test runs with NUnit.

2) Getting serious about Visual Studio (and Resharper) keyboard shortcuts
I have been quite happy to mouse along in Visual Studio, but watching some of the kata samples out there have brought home the usefulness (first for the kata, but already quickly apparent in my daily work) of using keyboard shortcuts to stay caught up to the train of thought. The 10 most-useful that I have started using regularly are:
* Ctrl-Alt-L to jump to Solution Explorer (and down and left hours to collapse projects)
* Ctrl-Tab to move between tests and code ("Active Files") and to other Visual Studio windows
* Shift-F10 instead of right-click (yes, I had to google that one)
* Option-R-U-N to run all tests in the Resharper window
* Alt-Enter to look at contextual Resharper recommendations (typically to invert if conditionals or switch declarative types to var)
* Alt-Shift-F10 to look at contextual Visual Studio recommendations (typically to either reference a using statement for a class, or to cascade a renaming across the code)
* F9 to set a breakpoint, and Ctrl-Shift-F9 to clear all breakpoints
* Ctrl-K-C and Ctrl-K-U to comment/uncomment code
* Ctrl-R-M to extract a method, and
* Ctrl-R-O to move a class to a difference namespace

3) Learning to use the simplest solution possible
It felt gimmicky at first, but solving two tests passing either "" or "3" to return 0 from the first, and 3 from the second, is most appropriately solved with:


return inputString.Length > 0 ? 3 : 0;

Of course that isn't "real", but it forces me to not overbuild. I notice that when I hit the more challenging issues to resolve (eg. the final requirement in the kata) that it's very tempting to start building the Sistine Chapel, but of course then the question becomes how do I test a coding monstrosity?

I'll come back to this one at the end, with it's implications for the coding of larger projects

4) Correspondence of test names and one-at-a-time issues to resolve
The Calculator kata states a series of issues to resolve. Each test is named with the resolution of that issue, for example:


[Test]
public void Calculator_Allows_Multiple_MultiChar_Custom_Delimiter()

It's very, very clear, and is a excellent parallelism to the original stated issues.

Overall Conclusions
I've written lots of unit tests over the last 3 years, and they have been extremely useful and provided signifigant code coverage (on my current project, I just passed the 300th unit test), but they, and the classes they address, tend to be large. I am using a domain model with NHibernate, I always practise moving business logic down (when it slips into the client or a service layer) into the domain object where it belongs, but then it tends to stop there. The domain model is correct, the logic is inside the entity, it prevents redundancy, all good things, but it makes for large entities and large tests, as opposed to more incremental tests shaping the design. In re-reading Refactoring [Fowler] this past November, I saw that smaller classes, with increasing delegation (eg. a domain entity calling out to a strategy class) makes for greater granularity, and with it, smaller tests. Starting from the tests-first, with the goal to keep the tests small and simple, helps to keep the classes small and delegating naturally.