Re: Pure virtual function call in Winamp?
On Oct 23, 11:50 pm, Andy Champ <no....@nospam.invalid> wrote:
James Kanze wrote:
On Oct 23, 8:47 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
Paavo Helde wrote:
"Robbie Hatley" <lonew...@well.com> wrote in
news:0cGdnaaabt2ruHzXnZ2dnUVZ_j-dnZ2d@giganews.com:
You cannot test for everything, especially if the problem
appears in a "very particular set of circumstances".
Yes, you can. Search for TDD
No you can't, and TDD isn't a silver bullet. (Some proponents
of TDD mail claim it does test everything, but they do so by
redefining "everything".)
I'm just going to chip in here and add my vote: James is
right (as usual!). There's no such thing as 100% test
coverage - it requires you to go through all paths, and that
is an enormous space on any reasonable program.
Literally, it would require you going through all paths with all
possible values for those paths. I don't think anyone claims
that this is possible, however, and most of the time, going
through all possible paths in each function is a close enough
approximation. (Floating point is a notable exception, given
its non-linearity. Multithreading also introduces some
limitations: unit tests are not normally run in a multithreaded
environment, and certainly not in a realistic one. These sort
of things create code which literally isn't testable.)
Even given this, the problem is guaranteeing that you've
executed all possible paths in each function. I've evaluated
tools claiming to do this in the past, and they all miss some of
even the more trivial cases. Done seriously (and that's an
important condition), TDD, and even more so code review, can
help, but they are both done by fallible humans, so some cases
slip through.
Our automated tests, run after every nightly build, currently
take about 100 machine hours (farmed out to a pool, so they
are normally done by morning!).
And I once, many years ago, had a bug which was a timing
problem between two routines. Once we had pinned down the
exact circumstances that could cause the fail we could make it
break most days. Sometimes it took longer than that for the
timing to get just right.
Timing problems and mathematical instability due to rounding
errors are probably the two most difficult things to catch
through testing.
--
James Kanze