From 586030d9702a03121e57a4326124b248732342e5 Mon Sep 17 00:00:00 2001
From: Tom Willemse
Date: Fri, 2 Jan 2015 21:04:36 +0100
Subject: Add old posts

---
 testing-with-lua.post | 121 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 testing-with-lua.post

(limited to 'testing-with-lua.post')

diff --git a/testing-with-lua.post b/testing-with-lua.post
new file mode 100644
index 0000000..96ac477
--- /dev/null
+++ b/testing-with-lua.post
@@ -0,0 +1,121 @@
+;;;;;
+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: -->
-- 
cgit v1.2.3-54-g00ecf