[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

testing syntax

This page is part of the web mail archives of SRFI 64 from before July 7th, 2015. The new archives for SRFI 64 contain all messages, not just those from before July 7th, 2015.



Any preferences for or against these changes?

(1) Move optional test-name to the end of the argument list?
E.g. instead of:
  (test-assert [test-name] expression)
  (test-eqv [test-name] test-expr expected)
it would be:
  (test-assert expression [test-name])
  (test-eqv test-expr expected [test-name])
Arguments in favor of the change:
- it is more common to have tthe oprional arguments be last.
- if we have forms with other optional arguments (such as
  discussed below) it s awkward to have one optional argument
  first and other optional argumemts elsewhere.
Argument in favor of the static quo:
- It is more readable to have the test-names first.  It is better
  in terms of documentation, things may line up better in columns,
  and it is easier to visually scan for a string near the start
  of an expression rather than near the end.

I'm inclined to think the latter arguments are more important,
but I'm not certain.

(2) Move the "expected value" argument *before* the "expression to
evaluate" argument.  E.g. instead of:
  (test-eqv test-expr expected)
we'd use:
  (test-eqv expected test-expr)
To illustrate, instead of writing:
  (test-eqv (vector-ref v 2) 99)
you'd write:
  (test-eqv 99 (vector-ref v 2))
Since both test-expr and expected can be arbitrary expressions,
this doesn't change test success/failure. However, it affects
failure messages.  E.g.
  FAIL: Test returned return 98 but expected 99.
Aubrey argued for this change.  It turns out JUnit also has the
"expected" value as the first operand.

(3) We need some routines for testing inexact numbers.
I suggested earlier:

(test-approximate [test-name] test-expression expected [error])
where is a relative error which defaults to 0.001.  Equivalent to:
  (test-assert (and (>= result (- expected (* expected error))
                    (>= result (+ expected (* expected error)))))

For absolute error bounds we could use:

(test-zero [test-name] test-expression [error])
where error is absolute and defaults (say) 0.001.  Equivalent to:
  (test-assert (and (>= result (- error)) (<= result error)))

Comments?  I think we need something like (3); I'm inclined to
making the changes in (2); and I'm conflicted wrt (1).
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/