chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Unit testing


From: Alejandro Forero Cuervo
Subject: Re: [Chicken-users] Unit testing
Date: Sat, 18 Nov 2006 01:06:00 -0500
User-agent: Mutt/1.5.11

> Please elaborate on "specify limits for the execution".

Well, I was thinking of setrlimit(2).  Perhaps also of setreuid(2).
Things like "this expresion should never take more than 5 seconds to
evaluate and no more than 1MB of memory" would be good.

> As far as "crash" proof goes, that will require something that traps
> memory exceptions, etc. None of the existing 3 support this.  Also
> requires a test results storage system that is incremental,
> transactional, & probably external. "test-infrastructure" constructs
> its' results in a functional manner, "check" is incremental but not
> safe, & "testeez" is incremental but not safe.

I was thinking of just forking a separate process that runs the test
and passes the result back over a pipe(2).

> I do maintain "test-infrastructure" but am not the author. Think I
> will make the necessary thread-safety changes.

I'm afraid using threads wouldn't be safe enough.  The tests would
probably test C code from the eggs.  If I understand how threads in
Chicken work, a bad low-level error in the tested code could easily
crash the whole testing process.

I guess my ideal implementation for defining tests would be along
these lines:

    (test-compare
      (car (cons 1 2)) ; expresion
      1                ; expected value
      equal?)          ; compare function

    (test-assert
      (cons 1 2)
      pair?)

We would have lots of files with all these tests (one for each egg).
And then we would reference them from another file as this:

    (run-tests
      "lists.scm"        ; file
      "Basic list tests" ; description of tests
      1                  ; max memory tests for each test (MB)
      5)                 ; max number of seconds for each test

This would generate a report for each test defined in lists.scm.
Each test would be run as its own process.  Ideally, the process would
set its UID to a specific user right before running the code.  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 (so I would probably also fork a process before actually running
the code from each file).  I also think run-tests should try to run
the tests both in compiled as in interpreted mode.

So, of the top of my head, that's it all.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]