Go

We’ll need to change the signature of our convert and Evaluate methods when there is a missing exchange rate. We are currently returning only one return value from these methods. To indicate an error — the inability to find an exchange rate — we need a second return value.

Here is the pseudocode for how Evaluate and convert should collaboratively work using Go’s idioms:

Evaluate:
    For each Money struct:
        Try to convert Money to target currency and add it to the total amount
            If convert returns an error:
                Capture the "from" and "to" currencies in "failures"
    If there are no failures:
        Return a Money struct with the total amount and target currency;
          return nil for error
    Otherwise:
        Return an empty Money struct; return an error message
          including all the failures

With this pseudocode sketched out, let’s write a failing test in money_test.go. This test will be slightly different from the existing tests: it expects an error to be returned and compares the error message with an expected message.

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

    oneDollar := s.NewMoney(1, "USD")
    oneEuro := s.NewMoney(1, "EUR")
    oneWon := s.NewMoney(1, "KRW")

    portfolio = portfolio.Add(oneDollar)
    portfolio = portfolio.Add(oneEuro)
    portfolio = portfolio.Add(oneWon)

    expectedErrorMessage :=
        "Missing exchange rate(s):[USD->Kalganid,EUR->Kalganid,KRW->Kalganid,]" 
    _, actualError := portfolio.Evaluate("Kalganid") 

    if expectedErrorMessage != actualError.Error() {
        t.Errorf("Expected [%s] Got: [%s]",
            expectedErrorMessage, actualError.Error())
    }
}

Expected error message should list each missing exchange rate; note the terminating comma

We don’t care about the first return value, so we assign it to the blank identifier

This test is similar to the two existing test for addition. We expect an error with the detailed message as the second return value from Evaluate method. We ignore the first return value by assigning it to the blank identifier.

We compare the expected and actual error messages directly in our test. We cannot use our assertEqual function as it currently exists because it can only compare Money s. We should improve this assertEqual function; we’ll defer it until the REFACTOR phase.

This code doesn’t compile. If we try to run it, we’ll get an error in money_test.go:

... assignment mismatch: 2 variables but portfolio.Evaluate returns 1 values

To get this test to pass, we first have to change the signature of the Evaluate method to return two values, the second one being an error. How would Evaluate know when to return an error? It would know if one (or more) of the calls to convert failed, because convert is where any missing exchange rates would be detected. This means that we have to change the signature of convert method, too.

Let’s redesign the convert method first, so that it returns a boolean to indicate whether the rate was found or not:

func convert(money Money, currency string) (float64, bool) { 
    exchangeRates := map[string]float64{
        "EUR->USD": 1.2,
        "USD->KRW": 1100,
    }
    if money.currency == currency {
        return money.amount, true
    }
    key := money.currency + "->" + currency
    rate, ok := exchangeRates[key]
    return money.amount * rate, ok
}

Method signature changed to return two values

We modify the signature of convert to add a second return type: a bool. If the “from” and “to” currencies are the same, the conversion is trivial as before: we return the money.amount unchanged and a true as the second return value to indicate success. If the “from” and “to” currencies are different, we look up the exchange rate in our map. We use the success or failure of this lookup, captured in the ok variable, as the second return value of convert method.

We have modified convert’s signature; we need to redesign Evaluate too.

import "errors" 
...
func (p Portfolio) Evaluate(currency string) (Money, error) {
    total := 0.0
    failedConversions := make([]string, 0)
    for _, m := range p {
        if convertedAmount, ok := convert(m, currency); ok {
            total = total + convertedAmount
        } else {
            failedConversions = append(failedConversions,
                m.currency+"->"+currency)
        }
    }
    if len(failedConversions) == 0 { 
        return NewMoney(total, currency), nil
    }
    failures := "["
    for _, f := range failedConversions {
        failures = failures + f + ","
    }
    failures = failures + "]"
    return NewMoney(0, ""),
        errors.New("Missing exchange rate(s):" + failures) 
}

The errors package is needed to create errors

If there are no failed conversions, a nil error is returned as the second value

If there are failed conversions, an error listing all the failed conversions is returned as the second value

There are several new lines of code; however, they are a faithful representation of the pseudocode we sketched out earlier. Manufacturing the error message string from the failedConversions slice requires a second for loop, but is conceptually straightforward.

With these changes, we get compilation failures in the the three other tests we have for addition. We get this error message, in triplicate:

... assignment mismatch: 1 variable but portfolio.Evaluate returns 2 values

Because we have changed the signature of Evaluate to return two values, we must also change the existing calls to this method to receive the second value, albeit with a “talk to the hand” blank identifier! One example is shown below:

    actualValue, _ := portfolio.Evaluate("USD") 

Assigning the second return value to the blank identifier indicates we don’t care about errors here

With these changes, all the tests now pass.

Time to refactor: let’s address the assertion if block in our newest test. We’d like to call the assertEqual method, but its signature currently requires two Money objects, whereas we want to compare two `string`s. The body of the method is fine as it is: it compares the two things it’s given and prints a formatted error message if they’re unequal.

Is there a way we could declare the two parameters to assertEqual in a more generic fashion?

Yes, there is. In Go, `struct`s can implement one or more `interface`s. The mechanism of this implementation is rather sublime: if a struct happens to be the receiver for all the methods defined in an interface, then it automatically implements that interface. There is no declaration in code explicitly saying “Hear ye! This struct hereby implements that interface.” (There isn’t a programmatic version of this town crier announcement, either.) Go’s interfaces are an interesting blend of static typechecking and dynamic dispatch.

Of particular interest is the empty interface, which defines exactly zero methods. Because the empty interface has no methods, it is implemented by every type.

Since the empty interface is implemented by every type, we can change the signature of the assertEqual method to accept an expected value and an actual value, both of which are of the type interface{}. We can then happily pass in two string`s or two `Money s, as we need:

func assertEqual(t *testing.T, expected interface{}, actual interface{}) { 
    if expected != actual {
        t.Errorf("Expected  [%+v] Got: [%+v]", expected, actual)
    }
}

The signature of this method is changed to accept two interface{} s, instead of two Money s

We can now replace the if block in TestAdditionWithMultipleMissingExchangeRates with a call to this modified assertEqual method:

func TestAdditionWithMultipleMissingExchangeRates(t *testing.T) {
...
    assertEqual(t, expectedErrorMessage, actualError.Error()) 
}

Call to the modified assertEqual method. Note that the last parameter is now actualError.Error(), to ensure type consistency with the second parameter

Neat! The tests are still green, and we have fewer lines of code. We have accomplished the three items listed in Table 10-1.

There is still duplication in the code: the bits where we create the key in both convert and Evaluate. We need to simplify our code. We’ll add it to our feature list.