Test Command

The command zune test <file> will run the test suite in the specified file, enabling the testing backend for zune.testing.

Testing is able to:

• Preview line in error tracebacks.
• Detect runtime memory leaks. (ideally for reporting as an issue for zune)

Making tests

Tests are conducted using the testing.test function. The function takes two parameters, a name and a callback function.

testing.test("Test Name", function()
    -- Test code here
end)

The test suite will run the callback function and check for any errors. If an error occurs, the test will fail.

Passing Example

 PASS (Test Name) [0ms]
 
 Tests: 1 total
 Time:  0.001 s

Failing Example

 FAIL (Test Name) [0ms]
 │ [string "filename"]:2: Error message
 │ path/to/filename:4:2: 0x123456 called error (test)
 │     error("Error Message") -- Test code here
 │     ^
 │ path/to/filename:9:1: 0x123456 called test (test)
 │ testing.test("Test Name", function()
 └─       ^
 
 Tests: 1 failed, 1 total
 Time:  0.001 s

Test Describing

Organizing tests can be done with then testing.describe function. The function takes two parameters, a name and a callback function.

testing.describe("Test Scope Name", function()
    testing.test("Test Name", function()
        -- Test code here
    end)
end)

An example of the scope can be shown below:

 PASS Test Scope Name (Test Name) [0ms]

If an error occurs in any test within the describe block, it would be an unexpected error, warning the error.

Expecting

The testing suite provides the testing.expect function to check for expected values.

testing.expect(1).toBe(1)
testing.expect(1).never.toBe(2)
testing.expect(1).toBeCloseTo(1, 0)

These functions act like assertions. If the value is not as expected, the expect function will throw an error.

Easy Integration

The testing suite is designed to be easy to use. The test suite can be disabled or enabled with zune run or zune test without extra configuration, allowing to you write tests within the same file as your code. Ideally, tests are mostly written on a separate file, but this is still an option for you to write tests on the same file without runtime errors.

While tests are disabled during runtime with zune run, the field zune.testing.running would be false, and test functions would be a NOOP and accessing nil results from expect().index would cause a runtime error. This could be used to know the running context.

local testing = zune.testing
 
if (testing.running) then
    -- prepare tests
    -- ... or you could use another testing library here.
    testing.test("Test Name", function()
        -- Test code here
    end)
end

NOOP

local testing = zune.testing
 
-- NOOP if testing is inactive
testing.test("Test Name", function()
    -- Test code here
end)
-- code continues

Example

local function add(a: number, b: number): number
    return a + b
end
 
if (zune.testing.running) then
    local testing = zune.testing
 
    local test = testing.test
    local expect = testing.expect
 
    test("1 + 2", function()
        expect(add(1, 2)).toBe(3)
    end)
 
    test("{} + {} (should error)", function()
        expect(function()
            add({}, {})
        end).toThrow("attempt to perform arithmetic (add) on table")
    end)
end
 
return add

Output:

> zune test path/to/module.lua
 PASS (1 + 2) [0ms]
 PASS ({} + {} (should error)) [0ms]
 
 Tests: 2 total
 Time:  0.001 s

Flags

Optimization Level

zune test -O=0|1|2 ...

Debug Level

zune test -g=0|1|2 ...

Native

Enables native code generation by default. This is the default behavior.

zune test --native ...

No-native

Stops zune from using native code generation by default. This does not remove the native code generation, checkout no-jit flag.

zune test --no-native ...

No-jit

Disables native code generation entirely.

zune test --no-jit ...

Limbo

Disables all of zune libraries.

zune test --limbo ...

No-fmt

Disables print formatting

zune test --no-fmt ...