Go

Let’s write a test in money_test.go to convert one Money struct into another, using a yet-to-be-created Bank :

func TestConversion(t *testing.T) {
    bank := s.NewBank()
    bank.AddExchangeRate("EUR", "USD", 1.2)
    tenEuros := s.NewMoney(10, "EUR")
    actualConvertedMoney, err := bank.Convert(tenEuros, "USD")
    assertNil(t, err) 
    assertEqual(t, s.NewMoney(12, "USD"), actualConvertedMoney)
}

func assertNil(t *testing.T, err error) { 
    if err != nil {
        t.Errorf("Expected error to be nil, found: [%s]", err)
    }
}

Verifying that there is no error

New helper function that does the verification

Inspired by how NewMoney works, we create a Bank struct (DNEY: does not exist yet) by calling a NewBank function (DNEY). We call an AddExchangeRate function (DNEY) to add a particular exchange rate to the Bank. We then create a Money struct, and call Convert method (DNEY) to obtain another Money struct in a different currency. Finally, we assert that there is no error during the conversion and that the converted Money matches our expectation based on the exchange rate. We wrote the assertion as a new assertNil helper function after the pattern established by the existing assertEqual function.

If there are too many concepts (structs and methods) that do not exist yet, it’s because we choose to go faster. We could always slow down and write smaller tests as we did early on in our journey, if we wanted.

We wrote our test with the assumption that the Convert method (DNEY) in Bank will have two return types: a Money and an error. Why did we change the signature of this Convert method from the convert method that already exists in Portfolio and returns a float64 and a bool? Because conceptually, the Bank converts money in one currency to money in another currency. The first return value, therefore, is Money and not just a float64 expressing an amount. The second return value is an error so that we can use it to indicate the exchange rate for the failed conversion, which cannot be done with a mere bool.

We are doing just-enough design based on what we know now. We’re neither speculating (over-designing) nor dumbing things down (under-designing).

To make this test green, we need to craft all the things that DNEY — do not exist yet. Let’s create a new source file in the stocks package named bank.go:

package stocks

import "errors"

type Bank struct {
    exchangeRates map[string]float64
}

func (b Bank) AddExchangeRate(currencyFrom string, currencyTo string,
        rate float64) {
    key := currencyFrom + "->" + currencyTo
    b.exchangeRates[key] = rate
}

func (b Bank) Convert(money Money, currencyTo string) (convertedMoney Money,
        err error) {
    if money.currency == currencyTo {
        return NewMoney(money.amount, money.currency), nil 
    }
    key := money.currency + "->" + currencyTo
    rate, ok := b.exchangeRates[key]
    if ok {
        return NewMoney(money.amount*rate, currencyTo), nil 
    }
    return NewMoney(0, ""), errors.New("Failed") 
}

func NewBank() Bank {
    return Bank{exchangeRates: make(map[string]float64)}
}

When conversion is successful, a Money and a nil (no error) are returned

When conversion fails, a placeholder Money and an error are returned

We introduce the missing concepts:

1. A type named Bank.

2. The Bank struct containing a map to store exchangeRates.

3. A function NewBank to create structs of type Bank.

4. A method named AddExchangeRate that stores exchange rates needed to convert Money s.

5. A method named Convert that is largely similar to the existing convert method in Portfolio. The return values are a Money and an error. If the conversion is successful, a Money is returned and the error is nil. If the conversion fails due to a missing exchange rate, a placeholder Money object and an error are returned.

With these changes carefully done, our new test passes.

We know that the existing behavior of Evaluate — which we need to retain — returns an error with all the missing exchange rates. Where will these missing exchange rates emanate from? The Convert method, when we use it in Evaluate shortly. This means that the error returned from Convert must include the missing exchange rate. We have it readily available in the Convert method: it’s in the variable named key. Even though replacing the hard-coded error message "Failed" with the variable key is a small change, let’s test-drive it. Why? It would also allow us to address the snotty little smell of returning the placeholder Money struct when there is an error. It’s better to have the two return values be symmetrical: convertedMoney should hold the result of conversion when err is nil and when the latter describes a conversion error, the former is nil.

Let’s write a second test to drill the proper error message and this symmetry into our Convert method.

func TestConversionWithMissingExchangeRate(t *testing.T) {
    bank := s.NewBank()
    tenEuros := s.NewMoney(10, "EUR")
    actualConvertedMoney, err := bank.Convert(tenEuros, "Kalganid") 
    if actualConvertedMoney != nil { 
        t.Errorf("Expected money to be nil, found: [%+v]", actualConvertedMoney)
    }
    assertEqual(t, "EUR->Kalganid", err.Error()) 
}

Converting Money in EUR to Kalganid

Asserting that a nil Money pointer is returned

Asserting that returned error contains the missing exchange rate

This test, TestConversionWithMissingExchangeRate, attempts to convert Euros to Kalganid — a currency for which no exchange rate has been defined in the Bank. We expect the two return values from Convert to be a Money pointer that’s nil and an error that contains the missing exchange rate.

This test fails to compile because of mismatched types:

... invalid operation: actualConvertedMoney != nil
        (mismatched types stocks.Money and nil)

This counts as a failing test. To allow nil values to be returned from Convert, we change the type of the first return value to be a pointer.

func (b Bank) Convert(money Money, currencyTo string) (convertedMoney *Money, 
        err error) {
    var result Money
    if money.currency == currencyTo {
        result = NewMoney(money.amount, money.currency)
        return &result, nil 
    }
    key := money.currency + "->" + currencyTo
    rate, ok := b.exchangeRates[key]
    if ok {
        result = NewMoney(money.amount*rate, currencyTo)
        return &result, nil 
    }
    return nil, errors.New("Failed") 
}

First return type is now a Money pointer

When conversion is successful, a valid pointer to Money and a nil error are returned

When conversion fails, a nil Money pointer and an error with missing exchange rate are returned

Running this test now gives us a failure message in an older test, TestConversion, reminding us about dereferencing pointers:

=== RUN   TestConversion
    ...   Expected  [{amount:12 currency:USD}]
               Got: [&{amount:12 currency:USD}] 

Expected a Money, got a Money pointer

That little ampersand & makes a world of difference! The actualConvertedMoney variable in TestConversion is now a pointer to a Money and needs to be dereferenced:

    assertEqual(t, stocks.NewMoney(12, "USD"), *actualConvertedMoney) 

The * dereferences the actualConvertedMoney pointer back into the struct it points to

With these changes, we get the assertion failure we are chasing:

=== RUN   TestConversionWithMissingExchangeRate
    ...   Expected  [EUR->Kalganid] Got: [Failed]

Replacing the string "Failed" with key in the Convert method gets the test to pass.

    return nil, errors.New(key) 

Last line of Convert method

We’re in the REFACTOR phase. One thing we can improve is our assertNil method. It’s only good for verifying if an error is nil; if it could take any type (like assertEqual already does) we could use it to assert that the Money pointer is nil, too.

Let’s try an implementation for assertNil following the lead of assertEqual:

func TestConversionWithMissingExchangeRate(t *testing.T) {
...
    assertNil(t, actualConvertedMoney) 
...
}

func assertNil(t *testing.T, actual interface{}) { 
    if actual != nil {
        t.Errorf("Expected to be nil, found: [%+v]", actual) 
    }
}

Using the modified assertNil to verify a nil pointer

Using empty interface to represent (almost) anything

Using the %+v verb to print non-nil values

With this implementation in use, we get an rather strange failure when we run our tests.

=== RUN   TestConversionWithMissingExchangeRate
    money_test.go:108: Expected to be nil, found: [<nil>]

That’s puzzling! If nil was expected and <nil> was found, what’s the problem?

Those little angle-brackets give us a clue. In Go, interfaces are implemented as two elements: a type T and a value V. The way Go stores a nil inside an interface means that only V is nil whereas T is a pointer to whatever type the interface represents (a *Money in our case). Since the type T is not nil, the interface itself is also not nil.

To use an analogy: an interface is like a wrapping paper and the box surrounding a gift. You have to rip it open to see what the gift is. It is possible that there is nothing inside the box — the ultimate gag gift — but you can’t find that out until you unwrap and unbox the gift first.

The way to unwrap an interface and examine the value inside is to to use the reflect package. The ValueOf function in that package returns the value V, which can then be checked by calling the IsNil function, also defined in the the reflect package. To avoid panic errors from inspecting nil interfaces, we must first check if the given interface{} is nil, too.

Here’s what the corrected assertNil function looks like.

import (
    s "tdd/stocks"
    "testing"
    "reflect" 
)
...
func assertNil(t *testing.T,actual interface{}) {
    if actual != nil && !reflect.ValueOf(actual).IsNil() { 
        t.Errorf("Expected to be nil, found: [%+v]", actual)
    }
}

We need the reflect package to examine the interface

The assertion error is raised if neither the interface{} itself is nil nor is the wrapped value

Excellent! Our tests all pass and we have the symmetric Convert method we set out to write. We’re ready to introduce Bank as a dependency of the Evaluate method in Portfolio.

Since we have a battery of tests for the Evaluate method, we’ll sally forth and redesign that method now. Any test failures we get — and we do expect to get many — will keep us on the RGR track.

We change the signature of the Evaluate method in Portfolio to have a Bank as the first parameter. We also change the type of its first return value to be a Money pointer. As for the body of the method, the changes are few and specific. We call Bank’s Convert method instead of the soon-to-be-retired local function convert. Whenever a call to Convert returns an error, we save the error message. Instead of returning a Money struct, we return a pointer to it. And when there are errors, we return a nil as the first value and the error as the second.

func (p Portfolio) Evaluate(bank Bank, currency string) (*Money, error) { 
    total := 0.0
    failedConversions := make([]string, 0)
    for _, m := range p {
        if convertedCurrency, err := bank.Convert(m, currency); err == nil {
            total = total + convertedCurrency.amount
        } else {
            failedConversions = append(failedConversions, err.Error())
        }
    }
    if len(failedConversions) == 0 {
        totalMoney := NewMoney(total, currency)
        return &totalMoney, nil 
    }
    failures := "["
    for _, f := range failedConversions {
        failures = failures + f + ","
    }
    failures = failures + "]"
    return nil, errors.New("Missing exchange rate(s):" + failures) 
}

A Money pointer and an error are returned

When the Money pointer is not nil, a nil error is returned

When there is an error, the a nil Money pointer is returned

With its signature changed, every call to Evaluate in our test fails to compile. We need to create a Bank and pass it to Evaluate. Could we do it once in money_test.go, and not within each individual test method?

Absolutely! Let’s declare a Bank variable outside all tests in money_test.go and use an init function to initialize this Bank with all necessary exchange rates:

var bank s.Bank 

func init() { 
    bank = s.NewBank()
    bank.AddExchangeRate("EUR", "USD", 1.2)
    bank.AddExchangeRate("USD", "KRW", 1100)
}

In money_test.go, outside any test method

New init function

Now we can use this bank in each call to Evaluate in our tests, e.g.: portfolio.Evaluate(bank, "Kalganid").

Since Evaluate now returns a Money pointer and an error, we have to change how we assign these return values to variables and how we assert for them.

Here’s how our TestAddition looks after making the necessary changes:

func TestAddition(t *testing.T) {
    var portfolio s.Portfolio

    fiveDollars := s.NewMoney(5, "USD")
    tenDollars := s.NewMoney(10, "USD")
    fifteenDollars := s.NewMoney(15, "USD")

    portfolio = portfolio.Add(fiveDollars)
    portfolio = portfolio.Add(tenDollars)
    portfolioInDollars, err := portfolio.Evaluate(bank, "USD") 

    assertNil(t, err) 
    assertEqual(t, fifteenDollars, *portfolioInDollars) 
}

Injecting the bank dependency into the Evaluate method

Asserting that there is no error

Dereferencing pointer to Money before using it as the last parameter in assertEqual function

After fixing the other tests similarly — using bank as the first parameter to Evaluate and dereferencing the pointer to get a reference to Money — we get all tests to pass. We’re now ready to remove the unused convert function in Portfolio. Deleting unused code is such a gratifying feeling!

Since we have a general-purpose and robust assertNil function available to our tests, we replace all blank identifiers _ with actual variables and verify that they’re nil. For example, in TestAdditionWithMultipleMissingExchangeRates, we can verify that the Money pointer is nil:

func TestAdditionWithMultipleMissingExchangeRates(t *testing.T) {
...
    expectedErrorMessage :=
        "Missing exchange rate(s):[USD->Kalganid,EUR->Kalganid,KRW->Kalganid,]"
    value, actualError := portfolio.Evaluate(bank, "Kalganid") 

    assertNil(t, value) 
    assertEqual(t, expectedErrorMessage, actualError.Error())
}

Receive the first return value, a Money pointer, in a named parameter instead of a blank identifier

Verify that a nil Money pointer is returned

We now have a much better code organization: Bank, Portfolio, and Money have specific responsibilities. We have robust tests that validate the behavior of all these types. A good indicator of our improved code is that each file in the stocks package is of comparable size: a few dozen lines of code. (If we write Godoc comments — which is a great thing — the files would be longer.)