So do you encourage people to add tests to their wrapper cookbooks when they consume these? I read the philosophy and readme docs, and I kindof get what your doing with attribute precedence, and how these cookbooks are sane defaults with overrides. Why not move to custom resources?
Also, what's your feelings about the chef monolithic repo?
Using custom resources, like LWRPs, doesn't provide the same flexibility. Most of the time you fall into making something which works akin to the `cron` internal resource which doesn't provide managing an entire system but instead a single entry which means you get neither automatic cleanup nor automatic fall back [to an earlier value]. It also means there's no good way to stack configs. You can (obviously) build a resource which manages the entire file/subsystem (poise does this, for example), but even then, you don't get the ability for everyone to override things later in the run... and we want the final service owner to be able to change anything anyone before them has set. It's a key part of being able to scale people... and for us to have such a small core chef team (4-5 people).
In addition, using simple hashes and arrays makes it much simpler for your average software engineer to make changes they want - they have to learn little to no Chef in the simple case... even not knowing ruby they can figure out variable assignments.
The monolithic repo works well for us given we use grocery-delivery (github.com/facebook/grocery-delivery). We have no environments (see my ChefConf keynote in 2013 for a full breakdown of how we do run things) and no cookbook versioning... we run directly off of head. We use a combination of taste-tester (github.com/facebook/taste-tester) for general testing and and sharding (see `node.in_shard?` and `node.in_flexible_shard?` in the `fb_helpers` cookbook) to control the speed of rollout of risky changes.
To be clear we use no precedences at all except `default` - using other precedences will in fact likely break our model since it causes the node-read code to merge things rather than treating it like a single hash. The model here is last-writer-wins always.
As for tests, people consuming these cookbooks are simply assigning variables, so there's not a lot to test in a wrapper cookbook. "Did the attribute get the value I assigned it" doesn't seem like a useful unittest... that should be covered by Chef's unittests itself. For our more complicated cookbooks we've unit-tested the API and where we could we released those (see fb_fstab), and we have some other unittests we haven't yet been able to release that hopefully we'll come back around to.