For a reasonable test for your Lua installation, follow these instructions:
appropriate_path/lua -e"_U=true" all.lua(If you do not provide an "appropriate_path", the system will probably use a previously installed version of Lua, which is likely to be incompatible with the test suite and not the one you want to test.)
The tests will print lots of different messages, but no assertion should ever fail. If the test goes all its way to the end, printing a "final OK" message, then all went well.
Note that, by its very nature, Lua is heavily dependent on the underlying standard C libraries. Sometimes the test suite fails because these underlying C libraries do not follow the ANSI standard. There is not much we can do about it.
The test suite uses some variables to control the execution
of some tests.
By defining the global variable
(e.g., with the option
-e_U=true in the command line),
the suite skip tests that are not fully portable,
that consume too much memory,
and that assumes 32-bit integers.
This option also suppresses messages for tests not performed.
should work without
problems in any system with Lua compiled without changes.
The complete test suite (that is, without the
tries to test every corner of the language, its libraries,
and the C API, even corners that are system dependent.
Unlike Lua itself, these tests do not aim at portability, small footprint,
or easy of use.
Their main goal is to try to crash Lua.
They are not intended for general use.
You are welcome to use them,
but expect to "get your hands dirty".
To run the complete suite,
first make sure your test directory has subdirectories
then go to subdirectory
build the C libraries there using the makefile provided
(or its equivalent to your system).
Now you may try to run the full test suite,
by running the following command at the top-level test directory:
Do not worry if it does not work the first time you try.
(That is why there is the
_U option after all.)
You may need to adjust small details for your system.
Among others, here is a list of things that may go wrong:
tmpnamcannot be opened or cannot be opened in write mode;
package.loadlib; see test
For even harder tests, Lua uses a special library, testC, that gives access to several internal structures in Lua. This library is only available when Lua is compiled in debug mode.
If you want to run these tests,
to the directory with the source Lua files,
and recompile Lua with the option
(or its equivalent to define
LUA_USER_H as the string
including the quotes).
This option not only adds the testC library,
but it adds several other internal tests as well.
After the recompilation, run the tests as before.
Again, expect to "get your hands dirty".