Test-driven design is good for external APIs which you are supposed to support for years, but not all that good for internal APIs which are supposed to be flexible and easy to change.
When you are creating external APIs you think long and hard about all imaginable use cases and one of the best ways to specify them is to write appropriate tests.
When you are designing internal APIs you usually change both producer (producers) and consumer (consumers) in tandem and prematurely written tests interfere quite heavily with this process. It's often better to write production code and then write tests. They could even be commited before the actual code but it'll be a mistake to write them before you know how real code will use the API (and if it's internal API then you don't need to imagine any other possible consumers: it's all there in your project).
Sadly most FOSS projects design external API in the same fashion internal APIs are designed which leads to lots of frustration everywhere.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds