-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 25, 2007, at 8:57 PM, Ivan Raikov wrote:
Yes, I actually meant testbase, but I wasn't paying attention when
typing. By the way, if I want to migrate my test code from testeez to
testbase, what should I use in place of the test-define macro? In
testeez, it is a convenient way to define constants local to a test,
but it is not clear to me how to do this in testbase.
Hi Ivan,
Depends where you are in your test container hierarchy.
At the top:
; From testeez document:
(define-test %foo:test Foo Station
(initial
; Bar function - sorry there isn't any keyed repository for
these things.
(define (bar x) (+ x 42))) )
; Bit of problem if this needed some 'bar' in the outer scope!
(test/equal Put two and two together (+ 2 2) 4)
(test/equal Bar scene (bar 69) 0)
(test/eqv Full circle (* (bar -21) 2) 42)
(test/eqv Multiple
(values (+ 2 2) (string #\h #\i) (char-upcase #\p))
(values 4 hi #\P
) ;%foo:test
Inside a test-case, test-suite, etc. (some kind of test container):
... outer ...
(test/case Foo Station (
[bar (lambda (x) (+ x 42))]
... )
... tests ...
)
... outer ...
or
... outer ...
(test-letrec ([bar (lambda (x) (+ x 42))] ...)
...
(some test) )
... outer ...
(I know, too many ways to do not quite the same thing.)
That said a 'test-define' macro isn't in the cards. While the name is
open, the body of a test container isn't, open that is. It is
actually a list of thunks, so there is no new scope once you enter
the clause body proper. (See below.)
(Really need a tutorial. In my copious spare time.)
Also, something
that testeez is lacking, but I would like to be able to do is test
loop invariants, e.g.:
(some tests ... )
(do ((i min (+ 1 i))) (( i max))
(some code ...)
(test/equal (some test ...) #t))
So if any of the tests in the loop fail, then there should be a way to
indicate that in the overall test stats. Is it possible to do this in
testbase?
Hmm, noo, but a good idea. I have thought of it.
The problem is each test is macroexpanded as a thunk in a list owned
by the enclosing test container. The machinery assumes each non-test-
container (i.e. an expectation) in a test container will have an
atomic value - a test result. This is one of the reasons for forms
like 'side-effect' and 'teardown'.
That said it becomes of issue of a generative test container.
Something like:
(test/collector
(do ((i min (+ 1 i))) (( i max))
(some code ...)
(test-collect (test/equal (some test ...) #t
(test-collector TSTNAM DTOR ESCR [(warn WARNING)] [((VAR VAL) ...)]
CLAUSE ...)
(test/collector [TSTNAM] [((VAR VAL) ...)] CLAUSE ...)
(test-collect CLAUSE)
The CLAUSE-body of a test-collector would function like a 'test-
case' (i.e. fail container on 1st test failure; assuming 'test-case-
evaluate-thru-failure' is #f). The collector container local form,
'test-collect', would append each test result as it is returned by
the CLAUSE. When the 'test-collector' container exits its' result
list then becomes a node in the results tree of the parent container.
Hmm. I will look into this.
BTW, one benefit of using 'expectations' is the ability to define new
ones:
(define-expect-unary procedure?)
...
(expect-procedure (make-format-function ...))
(define-expect-binary array-equal?)
...
(expect-array-equal (array '(3) 'a 'b 'c) (subarray ra 0 #f))
(define-expect-binary =)
(define-expect-binary/values =)
...
(expect-= 20.0 (ldexp 5.0 2))
(expect-=/values (values 5.0 0.5) (modf 5.5))
Best Wishes,
Kon
P.S. I inherited the architecture from 'test-infrastructure', and
never made any fundamental changes. One big change would be to shift
to a 'collector' style for every test form. The collector/collect
machinery would be invisible, essentially posting each test result
node as it is generated. Kinda late in the game though.
-Ivan
Kon Lovett [EMAIL PROTECTED] writes:
On May 24, 2007, at 7:28 PM, Ivan Raikov wrote:
Thanks for that useful addition. So if the tests require an
additional egg (such as test-infrastructure or testeez), should that
be added as a dependency in the .meta file?
Yes, but haven't done it myself yet.
(Note 'test-infrastructure' is obsolete.)
Best Wishes,
Kon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iEYEARECAAYFAkZX0joACgkQJJNoeGe+5O7p4gCfd4QsZHgL/AlSbz2fAox1IKhP
l4YAoILTxrpAvuI4ip8dXPdbkFpZJQyj
=1ivV
-END PGP SIGNATURE-
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
