;;;;;
title: Testing with Lua
tags: projects, lua, testing, ci, avandu-lua
date: 2014-06-30 23:32
format: md
;;;;;

Last time I wrote about my project
[avandu-lua](https://ryuslash.org/blog/?p=51) and I mentioned how I
was having some trouble testing the different types of functions. I've
since found a way to mock the functions in such a way that I can
safely test functions with IO operations without having to actually
perform them. It seems that Lua modules are mutable. Perhaps this
isn't strange given that Lua modules are basically tables, but I
hadn't considered it before. I'm not entirely sure if it is a language
feature or just something that happens to be true right now, so this
method of mine might soon become useless.

# Testing operations

So, to test these functions that would normally have side-effects or
would require a lot of extra work setting up to work correctly, we
basically have to replace the existing functions. Normally in a
running program you really wouldn't want to do this, save for when you
have dynamic scope, which I haven't yet found in Lua.

So I want to test that everything works properly when the `io.access`
function reports it can't access a certain file, I'd change the
function like so:

```
-- You must first require it, so you have the same module.
local posix = require 'posix'

-- ...

posix.access = function ()
   return false
end
```

This way I know what the function will do, when it eventually gets
called.

# Travis-CI

After finally getting some tests in my project and making sure that I
have full test coverage of my module, I thought it would be fun to see
if I could automatically test everything with travis-ci. It was a
little challenging because I don't normally run Ubuntu or Debian, so I
don't know what they name their packages, and one of my dependencies
(luasec) had some trouble finding the libssl library.

After a little poking around, a few retries and a false-success, it's
now finally running:

<div class="center">
  <a href="https://travis-ci.org/ryuslash/avandu-lua">
    <img src="https://travis-ci.org/ryuslash/avandu-lua.svg?branch=master" />
  </a>
</div>

My `.travis.yml` is pretty simple:

```
language: erlang

env:
  - LUA="lua"

branches:
  except:
    - gh-pages

install:
  - sudo apt-get update
  - sudo apt-get install luarocks libssl1.0.0
  - sudo luarocks install busted
  - sudo luarocks install luasocket
  - sudo luarocks install luasec OPENSSL_LIBDIR=/usr/lib/x86_64-linux-gnu
  - sudo luarocks install luajson
  - sudo luarocks install luaposix

script: "busted -m 'lua/?.lua' -o TAP"

# ...
```

I'm using the `erlang` environment, because there isn't a Lua one
(yet). I've written my library for lua, not luajit, so busted needs to
know which to run, it always runs luajit first it seems. I don't need
the tests to be run again when the `gh-pages` branch is updated, since
that has nothing to do with the code itself, I would actually like to
have tests run on all other branches.

Then we get to the dependencies. Nothing major except for the luasec
dependency. I'm not entirely sure how long that `OPENSSL_LIBDIR` will
remain where it is now, but it works for now. I didn't discover the
location myself, I found it on
[someone else's](https://github.com/ignacio/redis-luanode/blob/a50a7e5a9d0bd0c61b6ce7e445b278f2f184c792/.travis.yml#L41)
`.travis.yml` as a comment.

Lastly we have the script. Since the tests live in `/spec` and the
code lives in `/lua` I run the tests from the project root and include
the `lua` directory in the module path. I use TAP output because with
the default output failures also return `0`, when a failure occurs
with the TAP output, a non-0 exit status is returned and travis knows
they didn't pass. That is why build 6 passed even though there was
still a failed test.

The rest is notification settings which isn't interesting enough to
duplicate here.

# Still to do

Now I should start expanding it a little. Well, actually I *still*
need to add the proper license information.

<!-- Local Variables: -->
<!-- mode: markdown -->
<!-- End: -->