lua-users home
lua-l archive

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

> We used to do this at a company I worked with where we cared a lot. We
> did this for cryptographic toolkits expected to run on embedded
> devices, and we wrapped all our unit test suites in this kind of loop.
> It basically systematically fails every single malloc that might
> occur, not just at every call site, but in every call sequence (that
> is exercised by the test code). I've never seen a C library that
> survived a test loop like this, including ours, which we would write
> knowing that they would have to pass.

The standard tests for Lua include something along these lines, although
we cannot garantee every call sequence. And it does not test lua.c...

The allocator has a variable with the maximum memory it can use. The
test then proceeds to do some task (e.g., load a file) starting with a
zero limit and increasing it by small steps (something like 3 bytes)
until it is able to finish the task. All along the garbage collector
and the error recovery system are tested too. We do this test for
several tasks (creating a new state, new threads, loadstring, dofile,
string creation, constructors, closure creation, etc.).

-- Roberto