[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] chicken-setup -test
From: |
Kon Lovett |
Subject: |
Re: [Chicken-users] chicken-setup -test |
Date: |
Fri, 25 May 2007 23:22:50 -0700 |
-----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 <address@hidden> 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-----