Working Under Test-Driven Development

We're trying to submit some u-boot patches at work. The maintainer, Wolfgang Denk, has given us several useful suggestions about formatting.

First-cut, I wrote a utility that, I thought, would reformat code correctly. Not enough.

Yesterday, Jim Black, who's making the fixes, told me that instead of a pretty-printer, he wanted something that would just tell him when there were problems. I can do that.

"Also, there's a lot more rules," he said, showing me his growing list.

This time, I decided to create the screening tool using test-driven development:
I'd write a test case and a test, then write the code. I'm not done yet, but I have a growing suite of tests that test a tool of growing capability.

And, as we learn new rules, I'll just add tests as I add the capabilities.

This morning, in the shower, I thought of a fundamental design change I want to make to the overall tool. When I do it, I'll just run it through the test suite, to make sure it works.

Stay tuned.