Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #9274

Re: Two stages of debugging

Show all headers | View raw

On 9/18/18 12:46 PM, Julio Di Egidio wrote:
> On Tuesday, 18 September 2018 12:41:00 UTC+2, Wouter Verhelst  wrote:
>> On 9/17/18 10:31 PM, Victor Porton wrote:
>>> Which of the following two stages of debugging should be done first?
>>>
>>> 1. manual testing
>>
>> That's only useful while you're writing the code. At any point after
>> that, it should be automated.
> 
> Debugging is not testing.  And manual vs automated testing just hints at
> tests linked to the build/commit process, there is no difference as for
> the tests themselves.  Debugging is "manual", but debugging is not testing.

I am well aware of the difference.

You do need to test your code while you're writing it. I don't start
debugging things before I find a fault in my code; only when I do find a
fault will I try to debug it. But to be able to find a fault, you need
to... test.

You can do manual tests; depending on the environment, you can do that
by running functions from your code in a playground-type of environment,
or by compiling the program and running various random bits of its
functionality.

It is difficult to reproduce that, however, unless you automate things.

(I agree that the OP is not helping matters by being confused about the
difference, but that's not my fault)

>>> 2. proof-reading the code
>>
>> If you're interested in finding functional bugs (i.e., "the code should
>> do X but does Y instead), then proofreading code is an unreliable
>> method. Automated testing is a much more reliable way to do so.
> 
> Code reviews and testing should not be conflated, either: they do not even
> serve the same purpose.

I absolutely agree that code review can be useful. For instance, if you
want to see "is this a good way to go about doing whatever we want to
do", then code review (by a third party) is absolutely essential.

But as a method to find bugs, code review is unreliable.

>>> The purpose is to create quality code faster.
>>
>> IME, the best way to do that is to have a formal "everything must be
>> tested" policy.
> 
> Which is the 100% coverage nonsense, that you mean testing or that you
> mean debugging... ;)

I mean testing.

But no, here you completely misunderstand what I'm saying.

"100% coverage" is useless, I agree with that. But "everything must be
tested" does not imply "100% coverage".

When writing a test suite, parts of the code will be unreachable; bits
that are dead code, for example, will not be reached. Even so, dead code
can serve a valid purpose (e.g., you may write a function with an
assert() at the start, to ensure that no future code will ever try to
misuse the function in ways it was not written to support; but there are
other cases). So in any decent programming project, reaching 100% code
testing coverage is an implausible goal, and not one that should be
achievable.

However, there is another definition of "everything": "every feature the
program supports". Let's say you are writing a utility to copy files;
then you should test that:

- valid files get copied properly
- invalid command lines are properly rejected
- read errors and/or write errors during copying are properly handled
- if the utility supports progress information, that the progress
information is displayed accurately.
- if at some point in time you receive a bug report that the program
fails to run correctly when it is invoked on a friday the 13th, the bug
should be fixed, and following that (or concurrently with that), a test
should be devised that tests for the absense of the fault that caused
that bug, so that it does not reappear.

etc. That is, every bit of functionality which the user might interact
with must be tested.

If that means there are bits of code in the program which we currently
don't interact with, then it might be reasonable to avoid testing that,
or it might be better not to avoid that; it depends on the situation.

But what an "everything must be tested" policy like the above ensures is
that, lacking any new features, future versions of the code will have
less bugs, not more, and that way you will eventually converge on a
version of the program which is almost perfectly correct.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Two stages of debugging Victor Porton <porton@narod.ru> - 2018-09-17 23:31 +0300
  Re: Two stages of debugging David Brown <david.brown@hesbynett.no> - 2018-09-18 09:13 +0200
    Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-18 03:39 -0700
  Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-18 03:34 -0700
  Re: Two stages of debugging Wouter Verhelst <w@uter.be> - 2018-09-18 12:40 +0200
    Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-18 03:46 -0700
      Re: Two stages of debugging Wouter Verhelst <w@uter.be> - 2018-09-18 13:08 +0200
        Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-18 04:43 -0700
          Re: Two stages of debugging Wouter Verhelst <w@uter.be> - 2018-09-18 16:00 +0200
            Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-18 10:36 -0700
              Re: Two stages of debugging Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-09-19 07:51 +0200
                Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-19 03:43 -0700
              On the usefulness of testing coverage (was: Re: Two stages of debugging) Wouter Verhelst <w@uter.be> - 2018-09-19 13:46 +0200
                Re: On the usefulness of testing coverage (was: Re: Two stages of debugging) Julio Di Egidio <julio@diegidio.name> - 2018-09-19 08:20 -0700
            Re: Two stages of debugging Ed Prochak <edprochak@gmail.com> - 2018-09-18 12:02 -0700
              Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-19 03:39 -0700
  Re: Two stages of debugging Victor Porton <porton@narod.ru> - 2018-09-20 22:37 +0300
    Re: Two stages of debugging Julio Di Egidio <julio@diegidio.name> - 2018-09-20 12:53 -0700

csiph-web