Data Provider model

[ktalebian]

I'm looking to implement a DataProvider model, similar to to TestNG for Java testing. This is what I've done so far:

_G.dataProvider = function(test, ...)
	local arg = {...}
	local data = {}
	local provider = arg[1]

	if #arg == 1 then
		if type(provider) == 'table' then
			data = provider
		elseif type(provider) == 'function' then
			data = provider()
		else
			error('Unsupported type ' .. type(provider) .. ' provided')
		end
	else
		data = arg
	end

	for _, value in pairs(data) do
		test(table.unpack(value))
	end
end

Then a typical test would look like:

describe('util', function()
    -- Provider as a function
    local provider = function()
        return {
            {'expected-result1', 'arg1a', 'arg1b'},
            {'expected-result2', 'arg2a', 'arg2b'},
            ...
        }
    end
    
    -- Provider as a table
    local provider = {
        {'expected-result1', 'arg1a', 'arg1b'},
        {'expected-result2', 'arg2a', 'arg2b'},
        ...
    }
    
    dataProvider(function(expected, arg1, arg2)
        it('should run some test', function()
            assert.are.equal(expected, util.someMethod(arg1, arg2))
        end)
    end, provider)
    
    -- Or provider inline as multiple arguments
    dataProvider(function(expected, arg1, arg2)
        it('should run some test', function()
            assert.are.equal(expected, util.someMethod(arg1, arg2))
        end)
    end, {'expected', 'arg1', 'arg2'}, {'expected', 'arg3', 'arg4'})
end)

Looking to see if there are any better way of doing this with Busted, or if we can include this in the Busted framework natively.

[Tieske]

My preferred approach is to keep these close together (if you have a large test file, then the definition at the top of the describe block get separated from the actual tests using them. In those cases I use another describe block to keep them scoped smaller, and closer together.

There is no clear preference for any of the solutions you gave. There is a caveat though, of you have another function perform the tests, then and actual test failure will always get a stack trace pointing to that function. Doesn't make a big difference, just adds a bit of cognitive load to the debugging process.