On May 7, 2009, at 10:25 AM, Greg Knaddison wrote:
We have to temper the ideal with reality. We have several swappable systems in Drupal (database, mail sending, caching, others?) and as far as I know only one of them has multiple backends in core (databases). We are able to have multiple backend for databases, but it takes a lot of effort. I doubt we have the capacity to create not just 2, but 3 implementations for all of the other swappable items in core. There's also the question of baggage. Do we really want to merge SMTP [1] and Fastpath FSCache[2] into core? Would that be a total improvement? Would the additional complexity (usability decrease) be worth it just so we can satisfy a desire to properly test that APIs?
Also, the rules and corollaries I'm brainstorming are limited by the fact that I'm trying to fit them into Twitter-compatible 140-character snippets. It's a nice exercise in simplicity when explaining principles can easily veer into long digressions. ;-)
I agree that three implementations is better, because we're more likely to run into REAL variations, but as you say it's not necessarily realistic that very new API have three fully fleshed out example implementations. We can work towards it, and encourage it, but it's the "only one implementation" scenario that should really set off warning lights when we see it. The "write two" is mostly about smoke- testing for 'fake APIs' that look like swappable subsystems but are still too anchored to the original implementation to be replaceable.
Also, I don't think we necessarily HAVE to include each of our test implementations in core. But we should at least write them whenever possible, to flush out problems and also to reveal areas where 'perfect flexibility' isn't worth the overhead. (A persistence layer that can use SQL databases or XML files would be terribly flexible but probably not worth the work, for example.)
-eaton
