Echo AreaJust a blog, ok2014-06-30T21:32:28Ztekutihttp://blog.ryuslash.org/feed/atomTom Willemsenhttp://blog.ryuslash.org/Testing with Luahttp://blog.ryuslash.org/2014/06/30/testing-with-lua2014-06-30T21:32:28Z2014-06-30T21:32:28Z

Last time I wrote about my project avandu-lua 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:

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 .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.

Tom Willemsenhttp://blog.ryuslash.org/Avandu in Luahttp://blog.ryuslash.org/2014/06/27/avandu-in-lua2014-06-27T21:57:00Z2014-06-27T21:57:00Z

A little while ago I started using the Awesome window manager again. I���ve started to play some PC games (such as Rogue Legacy) and have to use some more graphical applications again. Stumpwm just wasn���t quite cutting it and suddenly it seemed that my workflow didn���t quite fit with a completely-manual tiling experience.

So now that I���m back with Awesome I wanted to have a count of the number of unread articles in Tiny Tiny RSS in my wibox. I already have a project named avandu, which is an Emacs interface for Tiny Tiny RSS, and for a little while I used that in combination with Emacs��� daemon mode to get the number of unread RSS items. This halt my Emacs for a few seconds every minute, though, so that was unpleasant. It also caused a lot of ���Connecting to host: …��� messages to appear in my Emacs��� echo area, which is a little annoying.

So I decided to write a lua module to get this count, since I didn���t have a lua project yet. That is avandu-lua. Right now it only implements a login and unread functions, which allow you to log-in to get a session key (so you can do other things), and get the number of unread articles (what a shock!).

I���ve written a bit of documentation for it, hosted by github. There isn���t much to document of course, but I try.

I still need to add tests, but I���m having difficulty deciding on how to do this. busted looks really nice, but their idea of stubs and mocks doesn���t seem to be very useful if you���re testing a function that calls, for example, http.call, which returns 4 distinct values, not none. I can���t decide if I should keep looking, (try to) write something or use _TEST checks everywhere. I���m leaning towards that last one, perhaps I���ll add that.

I don���t currently have any concrete plans of extending it to have more functions than the ones I���ve added so far, I might do it for fun at some point, or if you���d really like to be able to call Tiny Tiny RSS from lua let me know and I might put some more effort into it.

It���s been nice to work with lua. I don���t particularly love the language and it certainly doesn���t beat Lisp on any front, but it has its moments and niceties.

Some things that still need to be done:

  • As I said, I need to add tests.

  • I think I should try to see if coroutines can be used, it seems to hang Awesome now on occasion.

  • Add license info. Yeah I really should almost do this before I do anything else when I start a new project. It���s going to be LLGPL in any case.

  • Release an actual version. Always installing from just a git checkout can be a little annoying.