Live data from Hacker News

Using tests as a debugging tool for logic errors

qodo.ai

11–16 of 16 posts

Re: Using tests as a debugging tool for logic errors

#11

Earlier quoted context omitted.

I thought it was interesting - not revolutionary but updated my thinking a bit. Writing a failing test that reproduces a bug is something I learned pretty early on. But I never consciously thought about and approached the test as a way to debug. I thought about it more of a TDD way - first write tests, then go off and debug/code until the test is green. Also practically, let's fill the gap in coverage and make sure t…

I'm happy for you that you learned something and sad for me because you made me feel old and stupid. I tend to forget that people don't know stuff I learned decades ago and consider them as general knowledge. Before TDD became what it was, we used to create specific files for specific bug cases, or even get the files from the users themselves.

> I tend to forget that people don't know stuff I learned decades ago and consider them as general knowledge.

While all of us who are lucky to be around long enough meet the problem of general knowledge changing under our feet, it's hard for me to imagine how saying this to someone can be a productive contribution to the conversation. What can it accomplish other than making someone feel worse for not knowing something that you consider general knowledge?

Re: Using tests as a debugging tool for logic errors

#12
How do you determine if your tests are good at finding logic errors?

Mutation testing. Introduce artificial logic errors and see if your tests find them.

Disappointed the article didn't go into this. You can even use mutation as part of a test generator, saving the (minimized) first test input that kills a mutant. You still need some way of determining what the right answer was (killing the mutant just involves seeing it does something different from the unmutated program.)

Re: Using tests as a debugging tool for logic errors

#13
post #10

Closely related are in-code assertions. I remember when I used to liberally use asserts inside a code (and you could disable them for production) to check pre-conditions, post-conditions, or any invariants. Nowadays, I don't think the pattern is recommended anymore, at least in certain popular languages.

Fail as early as you can, if you can't recover.

Re: Using tests as a debugging tool for logic errors

#14
post #11

Earlier quoted context omitted.

I'm happy for you that you learned something and sad for me because you made me feel old and stupid. I tend to forget that people don't know stuff I learned decades ago and consider them as general knowledge. Before TDD became what it was, we used to create specific files for specific bug cases, or even get the files from the users themselves.

> I tend to forget that people don't know stuff I learned decades ago and consider them as general knowledge. While all of us who are lucky to be around long enough meet the problem of general knowledge changing under our feet, it's hard for me to imagine how saying this to someone can be a productive contribution to the conversation. What can it accomplish other than making someone feel worse for not knowing somethi…

I don't think anyone should feel bad for not knowing something.

My "general" knowledge is built on my experience.

The first comment before OP answer's was kinda condescending about the article and I felt the same way when reading it but then op's comment made me realise I was in the wrong because I forgot that my "general" knowledge is not general at all.

OP had to defend why he posted it. I wanted to tell OP that it was a good idea to post it, not for the article content, but for my teaching moment.

Re: Using tests as a debugging tool for logic errors

#16
post #10

Closely related are in-code assertions. I remember when I used to liberally use asserts inside a code (and you could disable them for production) to check pre-conditions, post-conditions, or any invariants. Nowadays, I don't think the pattern is recommended anymore, at least in certain popular languages.

It's not recommended as much anymore because of unit tests. Instead of peppering the code with asserts, you build tests based on those assertions. You don't have to worry about turning it off in production because the tests are separate, and you also don't have to worry about manually triggering all the various asserts in a dev build, because the test runs are doing that for you even before a build is published.
Post reply on HN