Speaking with Luke, I just had a thought about Test Driven Development:
it pushes implementation to parts of the application where developers are most proficient at testing.
Our concrete example here is a signup process, which has a number of steps that might be presented in a different order (a ‘track’) depending on what’s more relevant to the visitor signing up.
The simplest implementation
I feel like the simplest way to implement this is have a single, large form posting updates to the account, and present them in different orders accordingly. Certainly there could be some validation issues as the record is populated over a number of different updates, but I think in our case, that is fine.
I’ll state right now that I’ve no evidence that this would be the actual simplest implementation; that’s just my hunch, and I could be wrong.
Running away from the view
And so we’re torn. We want to write tests, but we want to write tests that we know are good. And we’ve got the most experience, and the most comfort, writing tests in Ruby using test/unit and shoulda.
A local minimum
So while we might end up with a pretty simple implementation that satisfies our sets, this might be a local minimum complexity.
I think the lesson here is that we need to become competent (and indeed fluent) in several different testing mechanisms if we’re going to be able to effectively arrive at simple implementations.
If you only have a hammer, everything looks like a nail.
Time to start learning some new testing techniques, I think.