Test suite for Lua 5.2

Basic tests

For a reasonable test for your Lua installation, follow these instructions:

• Download Lua 5.2 if you haven't already.
• Download the test suite for your release of Lua 5.2:

  5.2.0 · 5.2.1 · 5.2.2

• Open it anywhere; it will create a directory named 'lua-5.2.0-tests' (or something like that) with several .lua files and a few subdirectories.
• Go to this directory and run the following command:

      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.

Complete tests

The test suite uses some variables to control the execution of some tests. By defining the global variable _U (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. These basic tests should work without problems in any system with Lua compiled without changes.

The complete test suite (that is, without the _U option) 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 libs/ and libs/P1/, then go to subdirectory libs/ and 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:

    appropriate_path/lua all.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:

• small bugs in your system's C library;
• file names returned by tmpnam cannot be opened or cannot be opened in write mode;
• names in C libraries need a "_" prefix (only for function package.loadlib; see test attrib.lua);
• unconventional syntax for the command processor in os.execute.

Internal tests

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, copy ltests.c and ltests.h from the ltests directory to the directory with the source Lua files, and recompile Lua with the option -DLUA_USER_H='"ltests.h"' (or its equivalent to define LUA_USER_H as the string "ltests.h", 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".

Good luck!