That test driven development thing might just work

So, we have currency based limits and they’re in millions.

Us: “Are they always going to be in millions for all ccys?”

Them: “Yup.”

Coded, tested, delivered.

Them: “can we have the JPY limits in billions?”

Us: “US or European?” ;)

So now limits have exponents and exponents have names. I dummied up the functions to just return an exponent of 6 and a name of “m”. That worked. Then I added tests for it… I took out the “* 100000” and called the new getLimitValue() function that takes the display limit and applies the exponent…

And then I began to develop test first…

I changed the test for JPY so that it expected an exponent of 9 (US billions not European billions) and “bn” and the test failed because the method was hardcoded to return 6 and “m”… So I fixed the code in the simplest manner possible, and the tests worked.

So now I was left with a single function in the main application that used the limits and I just needed to alter that and I’d be done… In fact, I hoisted that code into the limits class to make it easier to test. Then wrote some tests for it and then made the tests work.

And it took less time than not doing the tests because the tests focused me on what I needed to do and allowed me to be sloppy to start with whilst I was understanding what was needed and then kept me straight whilst I cleaned it up.

And then they pointed out that what they actually wanted was not to manage the limits in billions but just to have values over 999 million displayed as billions… So we rolled back the changes and put in a simple display change.

You know, that onsite customer thing that the XPers do might be useful too…