Bruker:Jeblad/Module:BDD/dok

Note that the module is not ready for production, it is still under active development!

The purpose of this module is to support behavior-driven development (BDD), a software development process that emerged from test-driven development (TDD), in on-going development of Lua-based modules. It uses the assumption of a test module on a separate page, possibly a subpage, and presentation on the talk page.

The module implements some ideas from RSpec [1], Jasmine [2] and Busted [3]. All of which implements BDD.

The module is not built for great speed, it uses closures to build a number of small objects, that is methods returns a value that is wrapped in a closure. This makes a fairly efficient implementation for simple access, but it is not very efficient for caching larger structures. The module also avoids as much caching as possible, as this can poison the testing.

Usage

If you have a module like

local p = {}

function p.helloWorld()
	return "Hi there!"
end

return p

On the test page a call will then be something like the following

require 'Module:BDD'()

describe('Hello world', function()
	context('On all pages', function()
		it('says hello', function()
			expect(helloWorld()).toBe("Hi there!");
		end);
	end);
end);

return result('')

Further work

At present formatting does not work properly. It is expected to be fixed. ;)

Setup/teardown

There will be a solution whereby setup and teardown is chained. That means that the tests are somewhat isolated from each other at each test level, that is each time we define a describe, context, or it, the environment will be recreated. State can still leak between expectations though.

Pcall

All calls to provided functions should be protected in pcalls so a single exception does not make the whole test set to fail. A failed function should be marked as such in the report.

Spy on public calls

Note that spying on public calls made before the module is available to the testing regime will not be possible.

Carp: Adds a message to stack without exiting the test, printing the callers name and its arguments.
Cluck: Like Carp, but also prints a stack trace starting one level up.
Croak: Like Carp, but also stops the running test.
Confess: Like Cluck, but also stops the running test.

Stub public methods

It should be possible to stub public methods from the test page. This will not include private methods. (Is this something that should be part of a BDD module?)

Module return

At present an explicit return must be done. It seems to be possible to do an implicit return. This makes a slightly less error prone setup procedure.

Several options exist in literature, but it might be some limitations to what is actually allowed in Scribunto.