TDD – Touching The Gold (Part 2)

Last time we created our first unit test for our ShoppingCart class’ Add() method. We had made it out of The Thorns, and we were starting to touch The Gold. Today, we will extend this unit test.

As we left things, our first unit test was a simple one that only verified the presence of an item in our ShoppingCart after putting 3 Apples into it:

Rule 3 of the Three Rules of TDD implored us to write the least bit of implementation code to satisfy this unit test. To recap, Rule 3 is 

“Write no more production code than necessary to pass the one failing unit test.”

We passed the test by putting a dummy ShoppingCartItem into our cart:

That is our starting point for today.

Let’s clarify the assertion in our add-3-apples unit test to check that we have three apples in our cart: 

We’re more or less following TDD Rule 2: “Write no more of a unit test than sufficient to fail”. For the sake of expediency, I’m adding two assertions at once rather than just one.

Firstly, ShoppingCartItem is an empty class. We must add properties to it for Product and Quantity:

Setters are private—we’re not using them yet.

Unfortunately, the unit test is still failing to build:

Right. Let’s give public access to the Product’s Description property:

The unit test and all implementation code compiles:

Let’s run all unit tests.  The 3-Apples test fails:

It’s a NullReferenceException. How come we get this? 

We are trying to access the Description property on a null Product on the dummy ShoppingCartItem. 

We’ll fix this problem by creating the ShoppingCartItem specifically with three apples in the ShoppingCart.Add():

But now ShoppingCartItem does not have a suitable constructor. OK, let’s fix that too:

All the code builds. Let’s run the unit tests:

Yes! All tests pass.

It might not seem like we’ve come much further – our implementation code is still using a particular product (“Apple”) and quantity (i.e. 3). No?

On second thoughts, we did achieve much: We have extended the supporting ShoppingCartItem and Product classes’ behaviour. And we’ve set ourselves up for generalising our implementation code. Remember that as our unit tests get more specific, the implementation code becomes more generic. Until next time.