Re: [Chicken-users] Unit testing

[Alejandro Forero Cuervo]

> >Also, I think the test files should allow defining symbols that the
> >tests can use but that different files shouldn't be able to
> >interfere with each other
> 
> Please elaborate "defining symbols".

I was thinking that you might want to do something along the lines of:

    (define x (cons 1 2))

    (test-assert (pair? x))
    (test-equal? (car x) 1)
    (test-equal? (cdr x) 2)

    (define y (list 1 2 3))

    (test-assert (pair? y))
    (test-equal? (length y) 3)

However, you want to separate this as two sets of tests.  If the
"cons" crashed (in the real world this "initialization" code will
probably be far more sofisticated than just a cons), we wouldn't want
the whole set of tests to fail, just those that depend on it.  So the
above should probably be rewritten as:

    (test-group

        (define x (cons 1 2))

        (test-assert (pair? x))
        (test-equal? (car x) 1)
        (test-equal? (cdr x) 2))

    (test-group

        (define y (list 1 2 3))

        (test-assert (pair? y))
        (test-equal? (length y) 3))

That means that the only top-level forms should be macros from the
test API (and perhaps the (use ...); if that fails it can be assumed
that all tests will fail).

I realize I didn't properly explain what I mean by this in my previous
mail.  I'm sorry.

> I actually run my tests compiled by default as it is a more
> stringent  environment.

Well, running them both compiled and then interpreted has got to be
more stringent. ;-)

> Changing manner in which test results are captured to a "write"
> rather than a "cons" would be the big change.

Exactly, this is probably how I'd implement the test software. :-)

I'd define a protocol that allows a test to be executed by a certain
process and its result to be passed back to the parent process.  The
individual test forms would just fork, run the test and communicate
back the results (or, if they take too long, the parent would just
kill their process and record failure).  test-group in my examples
above would also fork and use the same protocol (though this time it
would be able to report the results of multiple tests back to the
parent).  And then you've got the parent that compiles the files
defining tests and also forks a separate process that sets its UID to
a "nobody" user and executes them.

Alejo.
http://azul.freaks-unidos.net/