Re: A simple unit test framework

Ian Collins wrote:
:: Pete Becker wrote:
::: Ian Collins wrote:
:::: Pete Becker wrote:
::::
:::: If you apply TDD correctly, you only write code to pass tests, so
:::: all of your code is covered.
::::
:::
::: Suppose you're writing test cases for the function log, which
::: calculates the logarithm of its argument. Internally, it will use
::: different techniques for various ranges of argument values. But the
::: specification for log, of course, doesn't tell you this, so your
::: test cases aren't likely to hit each of those ranges, and certainly
::: won't make careful probes near their boundaries. It's only by
::: looking at the code that you can write these tests.
:::
:: Pete, I think you are missing the point of TDD.
::
:: It's easy for those unfamiliar with the process to focus on the "T"
:: and ignore the "DD". TDD is a tool for delivering better code, the
:: tests drive the design, they are not driven by it. So if I were
:: tasked with writing he function log, I'd start with a simple test,
:: say log(10) and then add more tests to cover the full range of
:: inputs. These tests would specify the behavior and drive the
:: internals of the function.
::
:: Remember, if code isn't required to pass a test, it doesn't get
:: written.
::

So Pete will pass your first test with "return 1;".

How many more tests do you expect to write, before you are sure that Pete's
code is always no more than one unit off in the last decimal?

I know that he claims that it is. How can he do that?

Bo Persson