5 ms·

You know a better way of doing this? appsettings.Test.json Voila, different settings! I've said elsewhere, the DEFAULT should be super simple, really, really

You know a better way of doing this? appsettings.Test.json Voila, different settings! I've said elsewhere, the DEFAULT should be super simple, really, really, really easy to use. No thought, no effort, just use it. If you want to go all crazy and start injecting values into your config in your unit tests, great to have that option, you should have that option. But you're the one who should be scrabbling around writing tons of extra boilerplate code, not me. But I just want to set a filepath, that's probably never going to change, but might one day. Or an email address to send a weekly summary email to. Or some settings on paging that the client might change their mind about once and I don't want to have to rebuild the project. The vast majority of config settings are just cover your ass in case you need to one day change this value. They don't need to be tested. So it not the "normal" path to need to test config values. It's not the path the vast majority of programmers need.

sbelskie 6y ago
I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t even need to do anything with the configuration builder because that is part of the default of how the host gets setup. You’re configuration should be automatically built from environment vars and appsettings.json. And of course you can always just access environment variables directly if you want to.
- mattmanser 6y ago
  I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config<Settings>().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here's one (of many) questions asking simple questions on how to access config values in .Net core: https://stackoverflow.com/questions/46940710/getting-value-from-appsettings-json-in-net-core https://stackoverflow.com/questions/46940710/getting-value-f... 280k views! And look at the sheer length of that answer. If you think they succeeded in making a good configuration library, we have very different definitions of success.
  - nightski 6y ago
    It would be pretty trivial to implement the Env class you desire abstracting away the DI stuff.
  - maybeOneDay 6y ago
    The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff. Is this so hard? public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValue<int>( "AppIdentitySettings:Password:RequiredLength"), RequireUppercase = _config.GetValue<bool>( "AppIdentitySettings:Password:RequireUppercase") }; return View(vm); } }
    - mattmanser 6y ago
      Is this supposed to be ironic? Or just unintentionally? "What's hard about [mass of code] compared to [one liner]?"
      - maybeOneDay 6y ago
        The "mass" of code is an API controller, not just a way to get settings. It's an example of config use in real code. There are roughly 4 lines of code to get two variables out of the settings.json. This scales quite nicely - if we needed 8 different variables from settings then it would be 10 lines of code for 8 variables. Sure, it could be done in one line. My point wasn't to say that this is the most terse environmental variable code possible. My point was to say that it's disingenuous to say "look at the sheer length of that answer" as a way to state that the way to get env variables is hugely bloated. It's literally one ctor param and one private variable. If you don't like that for stylistic reasons, that's fine. I understand the argument saying "there should just be a static class with a readonly prop per variable", I just don't think that this particular code is in real terms actually any worse.
0xcoffee 6y ago
I'm going to have to disagree here. Having a settings object is much easier then appsettings.Test.json The .json is for running the application locally. A unit test should be able to cover if a setting has value 'a, b or c', which is much easier with a regular object.
- aidenn0 6y ago
  Making software harder to read, write, and maintain in the name of making unit tests easier to read, write, and maintain is putting the cart in front of the horse.
  - jolux 6y ago
    Indeed it would be but making unit tests easier to read, write, and maintain should force you to make the application easier to write and maintain. I agree that readability can suffer somewhat if you’re not careful though.
    - mattmanser 6y ago
      This is simply a dogma, if you want to follow that dogma, fine, but there's no reason to be forcing everyone else to.
      - jolux 6y ago
        I'm not going to force anyone else to, I am expressing an opinion. I would be pushing this position if I were on a team with you because it's not just a dogma, it reflects the best knowledge I have about how to build software well. You are free to build software as you see fit and have always been.
    - aidenn0 6y ago
      Writing quality tests is often much harder than writing quality software, and I find quality unit tests to be significantly harder than e2e or integration tests, so if I can only write software for which I can also write quality unit tests, I am greatly reducing the space of quality software I can write. Yes, one solution is to make the software more complicated in order to make the tests less complicated, but the other solution is to just use fewer unit tests. Note that I'm not advocating not testing (my motto with software is "If nobody tested it, then you can be certain it doesn't work."), but One good e2e test can often replace dozens of unit tests. I find that E2E -> Integration -> Unit form a scale from "easy to write, hard to run" on the e2e side and "easy to run, hard to write" on the unit side. There are exceptions; testing that you can sort N objects in M microseconds is a trivial test to write, and potentially a challenging requirement to implement, and a unit test might be completely appropriate there. However, for the general case, I find unit tests to be too often trying to make a square-peg fit a round-hole, and then saying "okay we'll shave the corners off a bit so that it's easier to fit in this hole" rather than saying "maybe we should use a square hole"

sbelskie 6y ago

I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t even need to do anything with the configuration builder because that is part of the default of how the host gets setup. You’re configuration should be automatically built from environment vars and appsettings.json. And of course you can always just access environment variables directly if you want to.

mattmanser 6y ago
I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config<Settings>().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here's one (of many) questions asking simple questions on how to access config values in .Net core: https://stackoverflow.com/questions/46940710/getting-value-from-appsettings-json-in-net-core https://stackoverflow.com/questions/46940710/getting-value-f... 280k views! And look at the sheer length of that answer. If you think they succeeded in making a good configuration library, we have very different definitions of success.
- nightski 6y ago
  It would be pretty trivial to implement the Env class you desire abstracting away the DI stuff.
- maybeOneDay 6y ago
  The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff. Is this so hard? public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValue<int>( "AppIdentitySettings:Password:RequiredLength"), RequireUppercase = _config.GetValue<bool>( "AppIdentitySettings:Password:RequireUppercase") }; return View(vm); } }
  - mattmanser 6y ago
    Is this supposed to be ironic? Or just unintentionally? "What's hard about [mass of code] compared to [one liner]?"
    - maybeOneDay 6y ago
      The "mass" of code is an API controller, not just a way to get settings. It's an example of config use in real code. There are roughly 4 lines of code to get two variables out of the settings.json. This scales quite nicely - if we needed 8 different variables from settings then it would be 10 lines of code for 8 variables. Sure, it could be done in one line. My point wasn't to say that this is the most terse environmental variable code possible. My point was to say that it's disingenuous to say "look at the sheer length of that answer" as a way to state that the way to get env variables is hugely bloated. It's literally one ctor param and one private variable. If you don't like that for stylistic reasons, that's fine. I understand the argument saying "there should just be a static class with a readonly prop per variable", I just don't think that this particular code is in real terms actually any worse.

0xcoffee 6y ago

I'm going to have to disagree here. Having a settings object is much easier then appsettings.Test.json The .json is for running the application locally. A unit test should be able to cover if a setting has value 'a, b or c', which is much easier with a regular object.

aidenn0 6y ago
Making software harder to read, write, and maintain in the name of making unit tests easier to read, write, and maintain is putting the cart in front of the horse.
- jolux 6y ago
  Indeed it would be but making unit tests easier to read, write, and maintain should force you to make the application easier to write and maintain. I agree that readability can suffer somewhat if you’re not careful though.
  - mattmanser 6y ago
    This is simply a dogma, if you want to follow that dogma, fine, but there's no reason to be forcing everyone else to.
    - jolux 6y ago
      I'm not going to force anyone else to, I am expressing an opinion. I would be pushing this position if I were on a team with you because it's not just a dogma, it reflects the best knowledge I have about how to build software well. You are free to build software as you see fit and have always been.
  - aidenn0 6y ago
    Writing quality tests is often much harder than writing quality software, and I find quality unit tests to be significantly harder than e2e or integration tests, so if I can only write software for which I can also write quality unit tests, I am greatly reducing the space of quality software I can write. Yes, one solution is to make the software more complicated in order to make the tests less complicated, but the other solution is to just use fewer unit tests. Note that I'm not advocating not testing (my motto with software is "If nobody tested it, then you can be certain it doesn't work."), but One good e2e test can often replace dozens of unit tests. I find that E2E -> Integration -> Unit form a scale from "easy to write, hard to run" on the e2e side and "easy to run, hard to write" on the unit side. There are exceptions; testing that you can sort N objects in M microseconds is a trivial test to write, and potentially a challenging requirement to implement, and a unit test might be completely appropriate there. However, for the general case, I find unit tests to be too often trying to make a square-peg fit a round-hole, and then saying "okay we'll shave the corners off a bit so that it's easier to fit in this hole" rather than saying "maybe we should use a square hole"