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

Groups > comp.programming > #9265 > unrolled thread

Two stages of debugging

Back to article view | Back to comp.programming

Contents

  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

#9265 — Two stages of debugging

Which of the following two stages of debugging should be done first?

1. manual testing
2. proof-reading the code

The purpose is to create quality code faster.

Automatic testing is nearly impossible for this project (because the tester 
needs to interact with PayPal).

The project is to be debugged again after refactoring.

It is https://github.com/vporton/django-debits

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#9269

On 17/09/18 22:31, Victor Porton wrote:
> Which of the following two stages of debugging should be done first?
> 
> 1. manual testing
> 2. proof-reading the code
> 
> The purpose is to create quality code faster.
> 
> Automatic testing is nearly impossible for this project (because the tester 
> needs to interact with PayPal).
> 
> The project is to be debugged again after refactoring.
> 
> It is https://github.com/vporton/django-debits
> 

If testing is going to be difficult or expensive, put more emphasis on
the proof-reading.  But try to get someone other than the programmers
who wrote it to do the checking.

And try to find some way to simulate at least parts of the system - you
should be able to get reasonable automated or semi-automatic tests of
much of the code even if you can't conveniently test the whole system.

[toc] | [prev] | [next] | [standalone]

#9271

On Tuesday, 18 September 2018 09:13:47 UTC+2, David Brown  wrote:

> And try to find some way to simulate at least parts of the system - you
> should be able to get reasonable automated or semi-automatic tests of
> much of the code even if you can't conveniently test the whole system.

Indeed, aiming for 100% coverage is counter-productive nonsense in any case.

Julio

[toc] | [prev] | [next] | [standalone]

#9270

On Monday, 17 September 2018 22:32:01 UTC+2, Victor Porton  wrote:

> Which of the following two stages of debugging should be done first?

You keep conflating testing with debugging and now with code reviews.  Where
alarming is not so much that you are misspeaking, but that you are actually
doing it.

> The purpose is to create quality code faster.

To go fast, don't go fast, just do it properly.  Which is already an advanced
lesson, but even if you don't know that, do you think you can run before you
can even stand?

> Automatic testing is nearly impossible for this project (because the tester 
> needs to interact with PayPal).

That is no reason, just mock it out.

> The project is to be debugged again after refactoring.

Tested and tested again, after any change.

Julio

[toc] | [prev] | [next] | [standalone]

#9272

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.

> 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.

> 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.

> Automatic testing is nearly impossible for this project (because the tester 
> needs to interact with PayPal).

So you write a service that acts enough like PayPal that your test suite
doesn't know the difference. It doesn't need to be fully functional, and
it can return the same answer to some API calls, but it needs to be just
enough so that your test suite sees the right result values, and so that
it fails when you send the wrong requests.

> The project is to be debugged again after refactoring.

You mean tested. Right, you can do that.

[toc] | [prev] | [next] | [standalone]

#9273

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.

> > 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.

> > 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... ;)

Julio

[toc] | [prev] | [next] | [standalone]

#9274

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.

[toc] | [prev] | [next] | [standalone]

#9275

On Tuesday, 18 September 2018 13:08:25 UTC+2, Wouter Verhelst  wrote:
> On 9/18/18 12:46 PM, Julio Di Egidio wrote:
<snipped>

> 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.

No, that altogether is called debugging: what the coder does while coding.
Testing is a separate phase, logically if not temporally, and, as I said and
as you seem to concur with below, with quite different purposes.

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

That's automated (i.e. scripted) debugging.  (One could say "little tests"
here, but it's totally informal and not to be confused with tests proper.)

Now, to be fair, the distinction between debug scripts and unit tests can
indeed be eliminated: but not conceptually, just practically, and just for
projects that are not too complex...

> However, there is another definition of "everything": "every feature the
> program supports".

I like the way you put it: that testing should be feature-wise, not code-wise.
Yet I'd argue that, even at that level, 100% coverage, now of the requirements,
is a rather counter-productive myth.  IOW, "certified" correctness can only
come from formal methods, while testing is the opposite of formal methods.

> less bugs, not more, and that way you will eventually converge on a
> version of the program which is almost perfectly correct.

That's another myth: the solution landscape is (nearly?) chaotic, so all you
converge to with a local approach is a local minimum, and a very suboptimal
one with probability (nearly?) one.  Indeed, that's one of the two or three
reasons why TDD in particular is like shooting in one's own foot, twice...

Julio

[toc] | [prev] | [next] | [standalone]

#9276

On 9/18/18 1:43 PM, Julio Di Egidio wrote:
> On Tuesday, 18 September 2018 13:08:25 UTC+2, Wouter Verhelst  wrote:
>> On 9/18/18 12:46 PM, Julio Di Egidio wrote:
> <snipped>
> 
>> 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.
> 
> No, that altogether is called debugging: what the coder does while coding.
> Testing is a separate phase, logically if not temporally, and, as I said and
> as you seem to concur with below, with quite different purposes.
> 
>> It is difficult to reproduce that, however, unless you automate things.
> 
> That's automated (i.e. scripted) debugging.  (One could say "little tests"
> here, but it's totally informal and not to be confused with tests proper.)
> 
> Now, to be fair, the distinction between debug scripts and unit tests can
> indeed be eliminated: but not conceptually, just practically, and just for
> projects that are not too complex...
> 
>> However, there is another definition of "everything": "every feature the
>> program supports".
> 
> I like the way you put it: that testing should be feature-wise, not code-wise.
> Yet I'd argue that, even at that level, 100% coverage, now of the requirements,
> is a rather counter-productive myth.

I agree that it's difficult to reach that. However, I argue that it is a
goal to aspire to (even if one that you should expect never to reach)

Can you explain why you think it is counter-productive?

> IOW, "certified" correctness can only
> come from formal methods, while testing is the opposite of formal methods.

Formally proving correctness is difficult for most complicated pieces of
software. If possible, I agree that it is preferable.

Pragmatically, I think testing things that you expect might go wrong by
just looking at the specs, as well as testing things that have been
reported to go wrong at some point in the past, is more than enough.

>> less bugs, not more, and that way you will eventually converge on a
>> version of the program which is almost perfectly correct.
> 
> That's another myth: the solution landscape is (nearly?) chaotic, so all you
> converge to with a local approach is a local minimum, and a very suboptimal
> one with probability (nearly?) one.  Indeed, that's one of the two or three
> reasons why TDD in particular is like shooting in one's own foot, twice...

The above statement assumed that the software is feature-complete. If it
isn't, then yes, at some point you need to write new functionality, and
that new functionality might be buggy (at least the first version of it
could be), so you introduce new bugs.

However, if your test suite is sufficiently complete, adding that new
functionality shouldn't introduce major new bugs in the already existing
code.

I vehemently disagree with the notion that TDD is like shooting in one's
own foot, and especially so if it would be doing so "twice". However, it
is important to set your expectations right; as with many things, there
is no silver bullet, and so you need to approach this with an
understanding that you can only catch the bugs you thought of when
writing your test suite, and the bugs you introduced but fixed in the
past. You can't do more than that.

[toc] | [prev] | [next] | [standalone]

#9278

On Tuesday, 18 September 2018 16:19:23 UTC+2, Wouter Verhelst  wrote:
> On 9/18/18 1:43 PM, Julio Di Egidio wrote:
> > On Tuesday, 18 September 2018 13:08:25 UTC+2, Wouter Verhelst  wrote:
> >> On 9/18/18 12:46 PM, Julio Di Egidio wrote:
<snipped>

> > Yet I'd argue that, even at that level, 100% coverage, now of the
> > requirements, is a rather counter-productive myth.
> 
> I agree that it's difficult to reach .

It's *impossible* *in principle*, and, as for all these myths, aiming for
it cannot but be a recipe for disaster under all respects: from the useless
extra effort, to expectations never fulfilled, finally to, which is the real
underlying fraud (talking about the whole arena now), the misunderstanding and
misrepresentation of the very state of the art.

> >> less bugs, not more, and that way you will eventually converge on a
> >> version of the program which is almost perfectly correct.
> > 
> > That's another myth: the solution landscape is (nearly?) chaotic, so all you
> > converge to with a local approach is a local minimum, and a very suboptimal
> > one with probability (nearly?) one.  Indeed, that's one of the two or three
> > reasons why TDD in particular is like shooting in one's own foot, twice...
> 
> The above statement assumed that the software is feature-complete. If it
> isn't, then yes, at some point you need to write new functionality, and
> that new functionality might be buggy (at least the first version of it
> could be), so you introduce new bugs.
> 
> However, if your test suite is sufficiently complete, adding that new
> functionality shouldn't introduce major new bugs in the already existing
> code.

Nope, even assuming that by some unspoken magic you get to the point of having
correct enough code and tests, adding any new features or changing existing
ones is still *not* a "local" change and does *not* guarantee any "continuity".
You change a random character in a million lines code and it won't even compile
in the general case, let alone remain correct.  --  And TDD is worse than
nonsense not just under that respect, more could be said, about the mythical
direct mapping of requirements (the problem domain) to specifications (the
solution domain)...

> However, it
> is important to set your expectations right; as with many things, there
> is no silver bullet

Which really is the self-apologetics of those myths: the denial of an actual
discipline and of an actual knowledge of what there is to know.  That stuff
is not simply not a silver bullet, that stuff is badly broken and badly
damaging, the entire category and the entire market...

Anyway, I might give more details if anybody asks, but I won't insist.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#9282

Julio Di Egidio <julio@diegidio.name> writes:
> On Tuesday, 18 September 2018 16:19:23 UTC+2, Wouter Verhelst  wrote:
>> On 9/18/18 1:43 PM, Julio Di Egidio wrote:

>> > Yet I'd argue that, even at that level, 100% coverage, now of the
>> > requirements, is a rather counter-productive myth.
>> 
>> I agree that it's difficult to reach .
>
> It's *impossible* *in principle*,

Strange.  DO-178B and DO-178C requires 100% MC/DC coverage (not only
100% statement coverage) for the most critical level of avionics
software.  As far as I know, that is routinely achived.  (Well, as much
as designing an airplane can be called routine.)

I'm not saying that it is the most cost-effective way of identifying
errors, but we have to respect that it actually works reasonably well.

Greetings,

Jacob
-- 
"There are only two types of data:
                         Data which has been backed up
                         Data which has not been lost - yet"

[toc] | [prev] | [next] | [standalone]

#9284

On Wednesday, 19 September 2018 07:51:55 UTC+2, Jacob Sparre Andersen  wrote:
> Julio Di Egidio <julio@diegidio.name> writes:
> > On Tuesday, 18 September 2018 16:19:23 UTC+2, Wouter Verhelst  wrote:
> >> On 9/18/18 1:43 PM, Julio Di Egidio wrote:
> 
> >> > Yet I'd argue that, even at that level, 100% coverage, now of the
> >> > requirements, is a rather counter-productive myth.
> >> 
> >> I agree that it's difficult to reach .
> >
> > It's *impossible* *in principle*,
> 
> Strange.  DO-178B and DO-178C requires 100% MC/DC coverage (not only
> 100% statement coverage) for the most critical level of avionics
> software.

Calling that the same 100% coverage we were talking about means the one
utterly confused is YOU.

Cut the bullshit for a change instead of systematically defending the
indefensible and *the criminal*: stupid bitches prefer that kind of men...

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#9285 — On the usefulness of testing coverage (was: Re: Two stages of debugging)

On 9/18/18 7:36 PM, Julio Di Egidio wrote:
> On Tuesday, 18 September 2018 16:19:23 UTC+2, Wouter Verhelst  wrote:
>> On 9/18/18 1:43 PM, Julio Di Egidio wrote:
>>> On Tuesday, 18 September 2018 13:08:25 UTC+2, Wouter Verhelst  wrote:
>>>> On 9/18/18 12:46 PM, Julio Di Egidio wrote:
> <snipped>
> 
>>> Yet I'd argue that, even at that level, 100% coverage, now of the
>>> requirements, is a rather counter-productive myth.
>>
>> I agree that it's difficult to reach .
> 
> It's *impossible* *in principle*

Nothing is impossible. Yes, it might be unfeasible, or it might be "so
much work that we'd need to build a test suite big enough to require a
test suite itself, and it's just not worth it, and our customers would
run away before we ever got there", but that doesn't make it
*impossible*. It's just software; as long as you stay within the realm
of software and have infinite time, *everything* is possible.

Choose your words carefully.

> and, as for all these myths, aiming for
> it cannot but be a recipe for disaster under all respects: from the useless
> extra effort, to expectations never fulfilled, finally to, which is the real
> underlying fraud (talking about the whole arena now), the misunderstanding and
> misrepresentation of the very state of the art.

You seem to be arguing that if something is your goal, and you never
reach that goal, that you've failed, by definition. That's fine, and in
that case I agree that 100% is a bad aim. But it's not what I'm arguing.

You can have a goal which is "something that would be nice if we reached
it", but not see it as critical. That can be a useful policy to have.

I'm also not arguing for test-driven development. With TDD, you write
the test suite first, and then write the software to make the tests stop
failing. I don't consider that a useful methodology. What I'm arguing
for, instead, is this:

- When you write specifications of the software, come up with a few
examples of what the software should do, and what it should not do. This
makes clearer to whoever is implementing the software what you are
expecting. Once you've written the software, those examples can be
reused as test cases for your software.
- While developing the software, you will obviously need to test it too.
If it's a library of functions, you might write small little programs
that call certain things in the library. Don't throw those small little
programs away, but keep them around, and put them in your test suite. If
it needs to be a GUI application, use a GUI framework that allows you to
inject fake events (e.g., fake mouse events). Use those to redo the
testing you did while developing the software, etc.
- When the software is ready, you will already have a test suite. You'll
have close to 100% coverage of the features of the software, unless you
didn't test something while writing it (which is bad practice).
- When you are made aware of a bug, write some code that uses your test
suite framework to reproduce that one bug. Then fix the bug. Now you'll
never reintroduce it again.

If the software ever reaches a maintenance-only mode (that isn't the
case for all software, but it is for some), then as bugs get reported
and fixed, you'll eventually reach a level where there are no bugs
anymore. You can't reintroduce the same bugs you introduced before
without noticing, because your test suite will help you with that. In
that case, you'll eventually also reach 100% coverage. Maybe.

It doesn't have to be a "we MUST reach this at some point" thing, but
even so having it as a low-priority goal to aim for can be useful.

>>>> less bugs, not more, and that way you will eventually converge on a
>>>> version of the program which is almost perfectly correct.
>>>
>>> That's another myth: the solution landscape is (nearly?) chaotic, so all you
>>> converge to with a local approach is a local minimum, and a very suboptimal
>>> one with probability (nearly?) one.  Indeed, that's one of the two or three
>>> reasons why TDD in particular is like shooting in one's own foot, twice...
>>
>> The above statement assumed that the software is feature-complete. If it
>> isn't, then yes, at some point you need to write new functionality, and
>> that new functionality might be buggy (at least the first version of it
>> could be), so you introduce new bugs.
>>
>> However, if your test suite is sufficiently complete, adding that new
>> functionality shouldn't introduce major new bugs in the already existing
>> code.
> 
> Nope, even assuming that by some unspoken magic you get to the point of having
> correct enough code and tests, adding any new features or changing existing
> ones is still *not* a "local" change and does *not* guarantee any "continuity".

I haven't even used the words "local change" or "continuity". You must
be using some random TDD-guru's terminology that I didn't invoke.

> You change a random character in a million lines code and it won't even compile
> in the general case, let alone remain correct.

That's precisely why testing your code with a good test suite is a good
thing! If you make a random change in one part of the code to fix a bug,
but you don't realize that part of the code also affects other parts
that you didn't consider, then your test suite will tell you that you're
an idiot and you will know to fix it.

But that only works if you test approximately everything, which you
claim is not useful. I still haven't seen why that is the case.

[toc] | [prev] | [next] | [standalone]

#9286 — Re: On the usefulness of testing coverage (was: Re: Two stages of debugging)

On Wednesday, 19 September 2018 13:46:31 UTC+2, Wouter Verhelst  wrote:

> That's precisely why testing your code with a good test suite is a good
> thing!

I haven't said otherwise...

> But that only works if you test approximately everything, which you
> claim is not useful. I still haven't seen why that is the case.

Yet I have told you why: also note that *impossible in principle* is more than
just not feasible in practice, it entails that one is going into the opposite
direction than is sensible and useful.  In particular, if you want to maximise
correctness (which is what I was objecting to you), you just won't get there
by going in the direction of maximising test coverage...

HTH and EOD.

Julio

[toc] | [prev] | [next] | [standalone]

#9279

On Tuesday, September 18, 2018 at 10:19:23 AM UTC-4, Wouter Verhelst wrote:
> On 9/18/18 1:43 PM, Julio Di Egidio wrote:
> > On Tuesday, 18 September 2018 13:08:25 UTC+2, Wouter Verhelst  wrote:

> >> less bugs, not more, and that way you will eventually converge on a
> >> version of the program which is almost perfectly correct.
> > 
> > That's another myth: the solution landscape is (nearly?) chaotic, so all you
> > converge to with a local approach is a local minimum, and a very suboptimal
> > one with probability (nearly?) one.  Indeed, that's one of the two or three
> > reasons why TDD in particular is like shooting in one's own foot, twice...
> 
> The above statement assumed that the software is feature-complete. If it
> isn't, then yes, at some point you need to write new functionality, and
> that new functionality might be buggy (at least the first version of it
> could be), so you introduce new bugs.
> 
> However, if your test suite is sufficiently complete, adding that new
> functionality shouldn't introduce major new bugs in the already existing
> code.
> 
> I vehemently disagree with the notion that TDD is like shooting in one's
> own foot, and especially so if it would be doing so "twice". However, it
> is important to set your expectations right; as with many things, there
> is no silver bullet, and so you need to approach this with an
> understanding that you can only catch the bugs you thought of when
> writing your test suite, and the bugs you introduced but fixed in the
> past. You can't do more than that.

Let me jump in here and say that I think you both are missing the
key question. What is the goal?

From both your comments, it seems you are focused on removing bugs.
And you are arguing over what are the best tools/methods to achieve
that.

The real goal should be producing systems that meet the requirements.
IOW the goal is to produce quality systems. This pushes the focus
up the line a bit more to the design.

Before debugging, code reviews, and QA testing, the design needs
to be analyzed to determine if it will meet the requirements.
And before that, the requirements have to make sense and be
achievable.

Now there is one other aspect of this discussion. Once you get to
design and implementation, you need to take a good look at what you
are building. The tools and techniques are going to be different.

Software is often compared to building so please let me use that
analogy for a moment. There are many ways to fasten together
two pieces of wood, and it makes no sense to argue in the abstract
which is best. Toenailing and dovetails are two very different
methods for example. Each one is wonderful for building products
in certain categories and pretty useless in others.

Even your tools and raw materials make a difference.
It is as hard to build quality decorative furniture from wafer board
as it is to build big data processing systems from 16bit computer
systems.

Similarly for software. For example I would say TDD and similar
iterative processes apply better where the functionality may be
hard to define, like user interfaces.

At the other extreme, a Waterfall model may work better for
"commodity" development where the requirements can be well
defined, such as a vending machine or garage door opener.

Bottom line is there is no one-size-fits-all development process.

I hope that sheds some light and isn't just smoke clouding the view.

Later,
   Ed

[toc] | [prev] | [next] | [standalone]

#9283

On Tuesday, 18 September 2018 21:03:00 UTC+2, Ed Prochak  wrote:

> From both your comments, it seems you are focused on removing bugs.

We are simply answering a question, you other stupid fuck.

> The real goal should be producing systems that meet the requirements.

That has been *my* lesson to morons and frauds like you for decades... but
just was not the argument here, you stupid fuck.

> Bottom line is there is no one-size-fits-all development process.

Some approaches work, some are STUPID SCUMS that people buy into because the
level of incompetence in this arena is second only to the level of dishonesty.

Just go fuck yourself.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#9290

Victor Porton wrote:

> Which of the following two stages of debugging should be done first?
> 
> 1. manual testing
> 2. proof-reading the code
> 
> The purpose is to create quality code faster.
> 
> Automatic testing is nearly impossible for this project (because the
> tester needs to interact with PayPal).
> 
> The project is to be debugged again after refactoring.
> 
> It is https://github.com/vporton/django-debits

The right choice was first test, then proof-read.

The reason for this is: Testing reveals *many* bugs, they need to be dealt 
first. The proof-reading is an *additional* measure to reach quality after 
there are no known bugs.

-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [next] | [standalone]

#9291

On Thursday, 20 September 2018 21:37:58 UTC+2, Victor Porton  wrote:
> Victor Porton wrote:
> 
> > Which of the following two stages of debugging should be done first?
> > 
> > 1. manual testing
> > 2. proof-reading the code
> > 
> > The purpose is to create quality code faster.
> > 
> > Automatic testing is nearly impossible for this project (because the
> > tester needs to interact with PayPal).
> > 
> > The project is to be debugged again after refactoring.
> > 
> > It is https://github.com/vporton/django-debits
> 
> The right choice was first test, then proof-read.

Congrats, the exact opposite than it's advisable.

> The reason for this is: Testing reveals *many* bugs, they need to be dealt 
> first. The proof-reading is an *additional* measure to reach quality after 
> there are no known bugs.

Code reviews still belong to the coding phase, and do resolve *lots* of bugs
*before they even occur*.  Testing is a later stage: logically and, where
needed, temporally.

HTH, even if it won't help you.

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web