21 ms·

I do write tests but I'm not a fan of aiming for 100% coverage because it's incredibly tedious to achieve, and the gains in my experience are marginal. That be

I do write tests but I'm not a fan of aiming for 100% coverage because it's incredibly tedious to achieve, and the gains in my experience are marginal. That being said even with 100% coverage your code may still contain bugs. If you've never had to debug code with extensive tests then hats off to you.

9rx 1y ago
When you write a test you see the cute little "debug test" button show up beside it in your editor. If you press it, your logpoints spill the logging information you seek without having to modify the code. I expect that is what the parent is really asking about: What does this meaningfully offer over the "built-in" debug logging?
- 0xFEE1DEAD 1y ago
  Well, my vim is missing buttons like these and I wasn't aware such a feature existed. Maybe I'm just old, maybe it's just a different approach, but I built dlg for myself because it fits my workflow. > What does this meaningfully offer over the "built-in" debug logging? For you, it most likely doesn't offer anything meaningful. For devs who use fmt.Printf a lot, it maybe does.
  - latchkey 1y ago
    I'm 52 and coding since I was about 10 years old, so I'm not sure age is the right thing to go off.
latchkey 1y ago
Crazy that I get downvoted for a perfectly valid question, go HN! I'm not saying that tests are perfect, but if you do find a bug, you write a new test and fix it. You don't add print statements that you expect to keep around any longer than the amount of effort there is to write the test and fix the code. Maybe this product is for people who don't write tests, but even in this codebase, there is a pretty well done set of tests and zero dogfood usage that I noticed.
- 0xFEE1DEAD 1y ago
  > but if you do find a bug, you write a new test and fix it. Maybe there's a misunderstanding here but this library is not meant to replace tests. It's for initially finding the bug for which you then write a test case (or not).
  - latchkey 1y ago
    It isn't clear how this library helps one find bugs.
    - danudey 1y ago
      If you're not sure how logging debug information can help you find bugs then I'm not sure what to say. Especially if you've been programming for four decades, I would think it would be obvious how logging information can help you find logic or data errors in your code/inputs/outputs.
      - latchkey 1y ago
        I know how to write failing tests, and use a debugger.
- danudey 1y ago
  I think you're getting downvoted because it's not a valid question - debug logging and unit testing are two separate things, and the OP didn't say anywhere that he prefers this to unit tests. Your question presupposes a dichotomy that doesn't exist.
  - latchkey 1y ago
    My statement certainly had some implied subtext that I can expand upon now... If you write tests, you don't need a specialized library for debug logging. Run the test, and set a breakpoint in your debugger.
    - 1y ago
0points 1y ago
> I'm not a fan of aiming for 100% coverage "100% coverage" is just a measure of line coverage and is highly useless to reason about. For testing to become meaningful, you should have test data covering way more than that for the relevant parts.

9rx 1y ago

When you write a test you see the cute little "debug test" button show up beside it in your editor. If you press it, your logpoints spill the logging information you seek without having to modify the code. I expect that is what the parent is really asking about: What does this meaningfully offer over the "built-in" debug logging?

0xFEE1DEAD 1y ago
Well, my vim is missing buttons like these and I wasn't aware such a feature existed. Maybe I'm just old, maybe it's just a different approach, but I built dlg for myself because it fits my workflow. > What does this meaningfully offer over the "built-in" debug logging? For you, it most likely doesn't offer anything meaningful. For devs who use fmt.Printf a lot, it maybe does.
- latchkey 1y ago
  I'm 52 and coding since I was about 10 years old, so I'm not sure age is the right thing to go off.

latchkey 1y ago

Crazy that I get downvoted for a perfectly valid question, go HN! I'm not saying that tests are perfect, but if you do find a bug, you write a new test and fix it. You don't add print statements that you expect to keep around any longer than the amount of effort there is to write the test and fix the code. Maybe this product is for people who don't write tests, but even in this codebase, there is a pretty well done set of tests and zero dogfood usage that I noticed.

0xFEE1DEAD 1y ago
> but if you do find a bug, you write a new test and fix it. Maybe there's a misunderstanding here but this library is not meant to replace tests. It's for initially finding the bug for which you then write a test case (or not).
- latchkey 1y ago
  It isn't clear how this library helps one find bugs.
  - danudey 1y ago
    If you're not sure how logging debug information can help you find bugs then I'm not sure what to say. Especially if you've been programming for four decades, I would think it would be obvious how logging information can help you find logic or data errors in your code/inputs/outputs.
    - latchkey 1y ago
      I know how to write failing tests, and use a debugger.
danudey 1y ago
I think you're getting downvoted because it's not a valid question - debug logging and unit testing are two separate things, and the OP didn't say anywhere that he prefers this to unit tests. Your question presupposes a dichotomy that doesn't exist.
- latchkey 1y ago
  My statement certainly had some implied subtext that I can expand upon now... If you write tests, you don't need a specialized library for debug logging. Run the test, and set a breakpoint in your debugger.
  - 1y ago

0points 1y ago

> I'm not a fan of aiming for 100% coverage "100% coverage" is just a measure of line coverage and is highly useless to reason about. For testing to become meaningful, you should have test data covering way more than that for the relevant parts.