On 7/6/06, Matthew Smillie <M.B.Smillie / sms.ed.ac.uk> wrote:
> Another code smell is an overuse of literals and constants, and this
> is equally the case for testing code as for production code.  This
> seems to me to be where the error really lies: you're using a
> constant in the testing code where you should be using a computed
> value based on the input.
>
> Knowing (as we do), that floating point calculations are not 100%
> accurate, a more reliable approach would be to make the test results
> using a parallel calculation to the code being tested, not simply a
> constant.

While I agree (mostly) with the rest of your post, I think this is an
oversimplification of the problem, and produces a "solution" more
painful than the "problem" iteslf.

You are right, that choosing the wrong delta for assert_in_delta can
be just as problematic as using Float#==. But I don't think that
throwing away assert_in_delta and using assert_equal with a parallel
calculation is the answer. In the trivial example you gave, it's fine,
since you've got one operation. But what if the method under test
performs many operations, due to complicated business rules?
(Hopefully those rules are factored out into their own tested methods,
but that doesn't stop them from being part of the behavior of that
method). Should we duplicate the entire process in the test? That
seems wasteful and error prone. I'll stick with assert_in_delta and an
expected value.

The important thing when dealing with floating point values is to
*always* know the domain and range (speaking mathematically) of your
function, then test those functions with appropriate deltas.

Jacob Fugal