Download the test suite for your release of Lua and follow the instructions below to run basic, complete, and internal tests.
If no test suite matches your release of Lua exactly, download the suite for the closest Lua release of the same version. Suites do not work across different versions.
The test suite is not a product; it is just a tool for our internal use. It is available here by popular demand but we cannot give any kind of support for it. You're on your own.
All files are distributed under this license. Check their checksums to confirm the integrity of the packages.
sha1: de77e590207a2fe03 4524f50848e56b748f24129
Open the test suite somewhere. You'll see a directory named lua-x.y.z-tests containing several .lua files and a few subdirectories.
To run some basic tests, go to this directory and run the following command:
path/lua -e"_U=true" all.luaMake sure you run the exact release of Lua that you wish to test. If you're in doubt, run lua -v and check the output. If the release numbers do not match, you'll have to provide an explicit path.
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
as done for the basic tests above),
the suite skip tests that are not fully portable
and that consume too much memory.
This option also suppresses messages for tests not performed.
The basic tests
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 that your test directory has subdirectories
then go to subdirectory
build the C libraries there using the makefile provided
(or its equivalent in your system).
Now you may try to run the full test suite,
by running the following command at the top-level test directory:
path/lua all.luaAgain, make sure you run the correct release of Lua.
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, the test suite 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, as described below.
If you want to run these internal 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 adds the testC library
and enables several other internal tests as well.
After the recompilation, run the tests as before.
Again, expect to get your hands dirty.