(2022-01-25) Jeffries Strawberries9 TDD
Ron Jeffries: Strawberries 9: TDD. TDD is too big a lump to be a good strawberry. Today I’m playing with TDD to try to find a bite-sized goodie. I expect not to accomplish that.
Curves made me think of a possibly interesting little thing to develop with TDD, a polynomial evaluator. The story might be something like this: Create an object, Poly, that can be given the coefficients of a single-variable polynomial in x, and which provides a single method to evaluate the polynomial at any given value of x. The object should work for any order of polynomial.
(Get Two Coefficients Working)
DIgression–or is it?
*I’m pretty proud of this and it’s really clear now that I can keep on doing this forever, for however many coefficients they want. I ask the polynomial person how many that is, planning my if statements, and they say “Lots, maybe over 100. It should work for whatever we provide.” Bummer. I don’t really want to type in that many if statements. I briefly consider generating the code on the fly and compiling it, but that seems wrong somehow.
We need a better idea. But we must digress again.*
Digression 2–or is it?
Our tests are going to allow us to experiment until we find a better more general design, even if it takes many tries.
Design Improvement Over Time
One thing seems obvious … we’re going to have to treat our input parameters as an array
I get a weird idea
What I’m doing is trying to get the calculations to look similar. And now I can almost see it happening
test("3x^2 +5x+7",
Those were honest, admittedly careless mistakes. The tests saved me.
But we’re not here to talk about building and testing polynomials, we’re here to talk about TDD and what it does for us. Once we had our polynomials of degree zero, one and two working, we refactored extensively:
All along the way, I made mistakes
the tests found them all.
All of this, a very complete redesign of Poly, was done while requiring no changes to our tests.
it lets us put in better more general code, or new capabilities, while giving us the confidence that we haven’t broken anything.
Without it, I’d be far less certain of design changes, to the point where I’d often be afraid to make them.
The TDD team maintains its interpretive view and its reactive view longer, which means that it can expand the capability of its behavioral view longer and with more ease.
Edited: | Tweet this! | Search Twitter for discussion