Skip to content

Latest commit

 

History

History
87 lines (61 loc) · 3.22 KB

README.md

File metadata and controls

87 lines (61 loc) · 3.22 KB
Raw

SPECL

License workflow status codecov.io

Specl is a testing tool for Lua 5.1 (including LuaJit), 5.2, 5.3 and 5.4, providing a Behaviour Driven Development framework in the vein of RSpec.

  • a rich command line program (the specl command)
  • textual descriptions of examples and groups (spec files use [YAML][])
  • flexible and customizable reporting (formatters)
  • extensible expectation language (matchers)

Installation

There's no need to download a Specl release, or clone the git repo, unless you want to modify the code. If you use LuaRocks, you can use it to install the latest release from its repository:

luarocks install specl

Or from the rockspec inside the release tarball:

luarocks make specl-?-1.rockspec

To install current git master from GitHub (for testing):

luarocks install \
  https://raw.githubusercontent.com/gvvaughan/specl/master/specl-git-1.rockspec

The dependencies are listed in the dependencies entry of the rockspec.

Documentation

Specl includes comprehensive documentation.

Bug reports and code contributions

Please make bug reports and suggestions GitHub Issues. Pull requests are especially appreciated.

But first, please check that your issue has not already been reported by someone else, and that it is not already fixed by master in preparation for the next release (see Installation section above for how to temporarily install master with LuaRocks).

There is no strict coding style, but please bear in mind the following points when proposing changes:

  1. Follow existing code. There are a lot of useful patterns and avoided traps there.

  2. 3-character indentation using SPACES in Lua sources: It makes rogue TABs easier to see, and lines up nicely with 'fi' and 'end' keywords.

  3. Simple strings are easiest to type using single-quote delimiters, saving double-quotes for where a string contains apostrophes.

  4. Save horizontal space by only using SPACEs where the parser requires them.

  5. Use vertical space to separate out compound statements to help the coverage reports discover untested lines.

  6. Prefer explicit string function calls over object methods, to mitigate issues with monkey-patching in caller environments.