Re: A simple unit test framework

Ian Collins wrote:
:: Bo Persson wrote:
::: 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;".
:::
:: Yes.
::
::: 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?
:::
:: You miss the point as well, I wouldn't be testing Pete's code, I'd be
:: developing my own. TDD is *NOT* retrospective testing.
::

Ok, then. If you were to develop a log() function, how many test cases would
you need for a black box testing?

Bo Persson