4 ms·

Lots of good stuff in there. One that caught my eye is “able to change logging level without code changes”. I would take that one step further to “without redep

by davedx 5y ago

Lots of good stuff in there. One that caught my eye is “able to change logging level without code changes”. I would take that one step further to “without redeploying”. Going to try and implement that in my own projects. I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there.

Stampo00 5y ago
I know this is meant more for backend applications than software meant to run on end user hardware, but... >able to change logging level without code changes The folks at Suckless would like a word. ;-) Personally, I think having to recompile software just to change settings is a royal pain in the butt.
- vasergen 5y ago
  agreed, I think this one comes from 12 factors apps methodology, see part III about config https://12factor.net https://12factor.net.
spyremeown 5y ago
>I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there. Hi, stupid junior here. Can you elaborate a bit or give me some reading material? I'm currently struggling to get good practices with tests and understanding associated metrics. Thank you!
- ollien 5y ago
  I'll take any chance to repost this: https://testing.googleblog.com/2010/07/code-coverage-goal-80-and-no-less.html https://testing.googleblog.com/2010/07/code-coverage-goal-80... That said, it's very easy to write tests that produce high code coverage, but do not test much that is useful (do they assert the things we truly need to check for?). It's also a pointless exercise to try and cover every single branch (e.g. does every defensive error check need to be asserted on?) It's a delicate balance and I'm sure some people will disagree with this, even.
- bromuro 5y ago
  “stupid senior” here! don’t listen to them :) always go for 90+% . lower coverage is laziness and may hurt sooner than expected. Sure full coverage doesn’t preve tu r you to write a bad test.
  - barakm 5y ago
    Another “stupid senior” here and I say go for 75-80%. It’s almost exactly a classic Pareto situation in my book. Parent post is right that lower coverage degrades rapidly... the difference between 65% and 75% is huge. But the ancestor post is right that there’s large diminishing returns too. I’ll qualify this with recommending leaning hard into lints and type checkers and the like. Eliminating whole classes of errors gives the edge; rather than writing test cases in, say, Python to ensure that a string-mangling function raises the “correct” exception if passed an int… just enforce mypy checking instead. And then get your type coverage up to 75-80 percent. Fuzzers too. Get more overall coverage by letting the computer do the work.
    - mathgladiator 5y ago
      I'm a stupid principal and I go for 100%... when I can. When I can't, I ponder. I see how my design can be aided by coverage and ask "Hey, I don't have coverage for this, why did I write it?" It's a worthwhile question. I wrote code, but it is hard to exercise easily... why did I write it? Don't get me wrong, there is a bunch of stupid shit to contend with (I'm looking at you MessageDigest AlgorithmNotFound)
      - ctvo 5y ago
        Of course I prefer 100% coverage with well written unit tests. But I’d also prefer to ship software and create value. There is a point of diminishing return in trying to exercise all code paths. Guessing at some hard rule (70%, no 80%!) seems futile as it varies depending on your own work. Experience tends to guide us to critical paths that should be tested at 100% and code generated RPC stubs that we may skip as an example. This is a trade off we make like so many in this field. Edit: we may be speaking pass each other. I agree that your code should be testable, and if it isn’t, it’s a code smell worth investigating. This is separate from the point of should every error thrown be exercised and every getter verified, etc.. With unlimited time and for some parts of the code sure, 100% though leaves 0 wiggle room here.
ryanrolds 5y ago
Agreed on the 90% unit test coverage. I'm all for high test coverage, but I care more about having solid assertions. Too often I see test that are expecting an error, but not the error it's getting. Major business rules need tests too, but they are much harder to write - so we get high unit test coverage and not hard conversations about test quality.
boffinism 5y ago
I prefer "Write tests. Not too many. Mostly integration." - Guillermo Rauch.

by davedx 5y ago

Stampo00 5y ago

I know this is meant more for backend applications than software meant to run on end user hardware, but... >able to change logging level without code changes The folks at Suckless would like a word. ;-) Personally, I think having to recompile software just to change settings is a royal pain in the butt.

vasergen 5y ago
agreed, I think this one comes from 12 factors apps methodology, see part III about config https://12factor.net https://12factor.net.

spyremeown 5y ago

>I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there. Hi, stupid junior here. Can you elaborate a bit or give me some reading material? I'm currently struggling to get good practices with tests and understanding associated metrics. Thank you!

ollien 5y ago
I'll take any chance to repost this: https://testing.googleblog.com/2010/07/code-coverage-goal-80-and-no-less.html https://testing.googleblog.com/2010/07/code-coverage-goal-80... That said, it's very easy to write tests that produce high code coverage, but do not test much that is useful (do they assert the things we truly need to check for?). It's also a pointless exercise to try and cover every single branch (e.g. does every defensive error check need to be asserted on?) It's a delicate balance and I'm sure some people will disagree with this, even.
bromuro 5y ago
“stupid senior” here! don’t listen to them :) always go for 90+% . lower coverage is laziness and may hurt sooner than expected. Sure full coverage doesn’t preve tu r you to write a bad test.
- barakm 5y ago
  Another “stupid senior” here and I say go for 75-80%. It’s almost exactly a classic Pareto situation in my book. Parent post is right that lower coverage degrades rapidly... the difference between 65% and 75% is huge. But the ancestor post is right that there’s large diminishing returns too. I’ll qualify this with recommending leaning hard into lints and type checkers and the like. Eliminating whole classes of errors gives the edge; rather than writing test cases in, say, Python to ensure that a string-mangling function raises the “correct” exception if passed an int… just enforce mypy checking instead. And then get your type coverage up to 75-80 percent. Fuzzers too. Get more overall coverage by letting the computer do the work.
  - mathgladiator 5y ago
    I'm a stupid principal and I go for 100%... when I can. When I can't, I ponder. I see how my design can be aided by coverage and ask "Hey, I don't have coverage for this, why did I write it?" It's a worthwhile question. I wrote code, but it is hard to exercise easily... why did I write it? Don't get me wrong, there is a bunch of stupid shit to contend with (I'm looking at you MessageDigest AlgorithmNotFound)
    - ctvo 5y ago
      Of course I prefer 100% coverage with well written unit tests. But I’d also prefer to ship software and create value. There is a point of diminishing return in trying to exercise all code paths. Guessing at some hard rule (70%, no 80%!) seems futile as it varies depending on your own work. Experience tends to guide us to critical paths that should be tested at 100% and code generated RPC stubs that we may skip as an example. This is a trade off we make like so many in this field. Edit: we may be speaking pass each other. I agree that your code should be testable, and if it isn’t, it’s a code smell worth investigating. This is separate from the point of should every error thrown be exercised and every getter verified, etc.. With unlimited time and for some parts of the code sure, 100% though leaves 0 wiggle room here.

ryanrolds 5y ago

Agreed on the 90% unit test coverage. I'm all for high test coverage, but I care more about having solid assertions. Too often I see test that are expecting an error, but not the error it's getting. Major business rules need tests too, but they are much harder to write - so we get high unit test coverage and not hard conversations about test quality.

boffinism 5y ago

I prefer "Write tests. Not too many. Mostly integration." - Guillermo Rauch.