3 ms·

I cannot imagine how handing over a code base with configs that themselves require testing can be smooth.

q3k 7y ago
I don't get it. If I get the choice between taking over a system where the configuration is self-tested, vs one that is not, I would much rather pick the first option? You don't _have_ to test anything, just like in any software development. But now you can, and you can do it in a side-effect-free environment, on CI push, instead of realizing you made a typo when the CM kicks in, or worse, when your system starts crashlooping on startup because of a configuration issue.
- jevgeni 7y ago
  If somebody hands over an application to me where configs have unit tests, this means to me that the application can fail catastrophically under certain (unwanted) configurations. And seeing how I might be the owner of said applications, chances are high that at some point I would need to change the configs. I, personally, would rather prefer straightforward static configuration and very well written documentation on why certain configurations make more sense than others. That way, I know how and when to change something in the configs. I absolutely do not share the view that "tests are documentation", because they do not communicate the most important thing in software engineering - the intent and reasoning behind a certain design.
  - jt2190 7y ago
    > If somebody hands over an application to me where configs have unit tests, this means to me that the application can fail catastrophically under certain (unwanted) configurations This would be a sign of a program that allowed input (configuration, in this case) that was unsafe. That is completely a different matter to whether a programing language is suitable for defining configuration. I suspect that many an application has been written that assumes that because it's consuming "static" configuration that is a simple text file, or a structured data file, that the input is completely safe. (SQL injection can come from any direction.)

q3k 7y ago

I don't get it. If I get the choice between taking over a system where the configuration is self-tested, vs one that is not, I would much rather pick the first option? You don't _have_ to test anything, just like in any software development. But now you can, and you can do it in a side-effect-free environment, on CI push, instead of realizing you made a typo when the CM kicks in, or worse, when your system starts crashlooping on startup because of a configuration issue.

jevgeni 7y ago
If somebody hands over an application to me where configs have unit tests, this means to me that the application can fail catastrophically under certain (unwanted) configurations. And seeing how I might be the owner of said applications, chances are high that at some point I would need to change the configs. I, personally, would rather prefer straightforward static configuration and very well written documentation on why certain configurations make more sense than others. That way, I know how and when to change something in the configs. I absolutely do not share the view that "tests are documentation", because they do not communicate the most important thing in software engineering - the intent and reasoning behind a certain design.
- jt2190 7y ago
  > If somebody hands over an application to me where configs have unit tests, this means to me that the application can fail catastrophically under certain (unwanted) configurations This would be a sign of a program that allowed input (configuration, in this case) that was unsafe. That is completely a different matter to whether a programing language is suitable for defining configuration. I suspect that many an application has been written that assumes that because it's consuming "static" configuration that is a simple text file, or a structured data file, that the input is completely safe. (SQL injection can come from any direction.)