7 ms·
Let's say you want to test bootstrapping your system with various configurations. You could make a few dozen different configuration files. Or maybe it's more
by stickfigure 2y ago
Let's say you want to test bootstrapping your system with various configurations.
You could make a few dozen different configuration files. Or maybe it's more than that because you want to test permutations. Now you're maintaining a bestiary.
So instead you think "I'll write code that generates the config file for each test". And that's reasonable sometimes.
On the other hand, the single-responsibility principle can be reasonably applied here and "reading the config data" is a good single responsibility. You don't want to have to write code to muck with json or xml every time some component needs a configuration value. So there should already be a clean boundary here and it often makes sense to test the components separately.
There's not one rule. The article author sounds like an excitable jr engineer that's never written software at scale.
- dogleash 2y ago> that's never written software at scale. Is this like a never version of that insult where people would say someone's opinion doesn't matter because they worked on a project that never shipped (regardless of how much or how little they contributed to the failure)? Just replacing it with an AWS bill-measuring contest?
- stickfigure 2y ago"Software at scale" is different from "data at scale" is different from "compute at scale". But yeah, when I hear "STOP MAKING SERVICES AND FACTORIES AND INTERFACES AND JUST READ THE FUCKING JSON FILE YOU ENTERPRISE FUCKERS" I think "developer who's never worked on anything more complicated than a chat app, and isn't old enough to have learned humility yet".
- deleted 2y ago[deleted]
- pphysch 2y ago> Now you're maintaining a bestiary. Any battle-hardened test suite is already a bestiary. Having a subfolder of diverse & exemplary config files, that could be iterated over, is not adding much to the pile.
- stickfigure 2y agoA totally reasonable approach! Sometimes.
- nucleardog 2y agoThe interface in question is `IConfigurationFileService`. I can only guess at the actual interface, but based on the name it doesn't sound like it's abstracting away the need to put your configuration into files. Could just be a case of bad naming and it solves everything you're saying. But it sounds like pointless enterprise-y fuckery to me. I would not say the same thing about `ConfigurationFileService : IConfigurationLoader` or something.