Initial commit.
"An empty string returns zero" is our first test.
Currently failing because we've not actually got an implementation of
StringCalculator to use with it.
Provided an implementation of StringCalculator to get the test to pass.
Good job it was a small step, since as is often the case, the mistake
I'd made wasn't the one I thought I'd made. In this case, I'd forgotten
the 'do' after 'context' in the spec, so it wasn't able to start the
block.

Thanfully, my change is small enough that it's easy to spot and rectify
these things that would be a lot harder with a bigger commit.
First test passing now that we've got the right argument being defined
on calc method.
Introduced my second test (currently failing) to triangulate the
implementation of the StringCalculator.

Also removed the duplication in my specs so that I don't end up having
the same preamble of creating the StringCalculator in each and every
spec. That should allow the intent of the spec to stand out from the
boilerplate.
Simplest implementation that passes both specs.
Failing spec for
Two numbers, comma delimited, returns the sum
Passing with what seems to be the most obvious implementation given the
existing constraints of the tests.

Had a quick check for duplication after the tests passes. No obvious
opportunities to remove duplication, or clarify the intentions of the
code.
Added failing test for Two numbers, newline delimited, returns the sum
Test now passing, but the implementation is at the bounds of what I'd
like to have in terms of expressiveness. Unless you're regularly dealing
with regular expressions there's stuff going on in that pattern that
could do with a little explanation.
With that refactoring, the implementation is a little easier to read,
but it's not quite as obvious as I'd like it. Let's see what influence
the remaining tests have.
Added test for Three numbers, delimited either way, returns the sum
Passing straight away with the current implementation. Let's see what
additional constraints from the next test will force us to evolve our
design.
Added test for Negative numbers throw an exception. Currently failing.
Good. Time to make it pass and then refactor.
Test passing. Time to refactor.
The calc method was getting a little on the long side and also had too
much nesting, so I refactored it to introduce a couple of new explaining
methods. This also means that the calc method has fallen in line with
the composed method philosophy in which the methods are small and each
statement within the method is at the same level of abstraction.
Added the next test which says that Numbers greater than 1000 are
ignored. Immediately noticed that this would require a bit of a change
and that the best way forward would be to identify a change site and
work below that boundary. Spotted the opportunity to refactor the code
and introduce than boundary - evaluate_elements - but I was failing, so
I pended the failing test since I always refactor on green!
Refactored evaluate_elements to allow me to consider individual numbers
to add.
Given the refactoring is in place, I can now un-pend the failing spec
for numbers over 1000.
Spec to ignore numbers greater than 1000 is now passing. Time to
refactor.
Looking over the spec, it looks like although I'd removed the pending
keyword from "ignores numbers greater than 1000", I'd accidentally left
the string in. It didn't have any effect on the execution, but it was
standing in the way of readable specs. Let's leave things better than we
found them.
replace_commas_and_newlines_with_pluses(input) is no longer called. It's
dead code. We can remove it to keep the implementation clean.