Said Here

I’ve been writing my unit tests with assert(), and it works ok.

But, I’d like to split my test suite across multiple files, I’d like to run all or just a part of the suite, and I’d like, when a test fails, to rerun just that specific test, or tests matching a pattern.

So, I need a better tool, and I want to choose one I can stick with for a while. I looked around at what I could find, starting with the ones listed on the lua wiki.

Analysis is below, but the conclusion is that lunit was the winner.

Still, one feature wasn’t working on the master, and I had some trouble finding a good way to integrate into some of our codebases. So, I forked it, and pushed some changes to github.

lunit.lua
---------

- Source: 

- Has a weird shell-script wrapper, but not necessary to use,
just call lunit.main().

- The lunit script fails for me (down.lua) with bizarre error
 messages when using -t, not sure why, and its construction
 makes it hard to figure out!

- Distinguishes between error/assert and it's internal assertions.

- Doesn't accept a fmt string  + .. for the assert msg

- Should support a -t argument, but I'm having trouble using
it from lunit. It does work from lunit.main(), but irritatingly
 involves matching the entire test name, which I fixed.

lunity.lua
----------

- Source: 

- Seems to be a not-well-justified clone of lunit, basically
feature  compatible, with slightly different names, and two
missing features.

- There isn't any way to report over tests from multiple
modules, other than just running them individually.

- Doesn't distinguish between errors (calling nil, bad calls,
etc.) and unit test assertions.

moonunit
--------

- Source: 

- Too simple to be considered.

luaunit
-------

- Seems like a port of pyunit's OO framework, unnecessarily heavyweight for lua.

shake
-----

Too weird, and doesn't allow running single testcases.

...
---

All the behaviour and spec driven were way too heavy-weight,
 and syntactically noisy. Also, a decent BDD or spec-based
 framework should layer on _top_ of a lower-layer of unit
tests, so it can be combined with other approaches.

This entry was posted on Friday, April 9th, 2010 at 6:26 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.