立即在脚本中调用的测试代码
Testing code immediately invoked in a script
我目前正在使用 Busted 为 lua mod 库编写单元测试。有问题的文件定义了一个带有一些函数的 module,然后在底部调用其中一个函数来初始化自身。
我发现的问题是 Busted 似乎对所需输入文件进行了两次 lua 处理。
测试
it('does a thing', function()
-- Some setup, replacing globals etc
require('items')
assert.are_equal(2, #Items._registry)
end)
模块
Items = { _registry = {} }
function Items.do_some_stuff() end
function some_util_func() end
function load_registry()
print(debug.traceback())
for i, itm in pairs(Items.do_some_stuff()) do
Items._registry[i] = itm
end
end
load_registry()
如您所见,虽然我简化了代码和名称,但结构并没有什么特别的(据我了解。)
测试总是会失败,因为 #Items._registry
总是 0(并且转储到控制台可以验证这一点)。我尝试在方法内部打印,发现它打印了两次;然后我尝试在那个油膏的顶部使用 debug.traceback
并找到下面的内容。如您所见,堆栈回溯打印了两次,表明代码被 evaluated 两次。
其他人遇到过这种情况吗?我是否针对这种情况构建了错误的测试?或者这是一个错误?
stack traceback:
items.lua:96: in function 'load_registry'
items.lua:109: in main chunk
[C]: in function 'require'
spec/items_pec.lua:50: in function <spec/items_spec.lua:39>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/init.lua:40: in function 'executor'
/usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
...
/usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/local/share/lua/5.2/busted/block.lua:155: in function 'execute'
/usr/local/share/lua/5.2/busted/init.lua:7: in function 'executor'
/usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/local/share/lua/5.2/busted/execute.lua:58: in function 'execute'
/usr/local/share/lua/5.2/busted/runner.lua:174: in function </usr/local/share/lua/5.2/busted/runner.lua:11>
/usr/local/lib/luarocks/rocks/busted/2.0.rc12-1/bin/busted:3: in main chunk
[C]: in ?
stack traceback:
items.lua:96: in function 'load_registry'
items.lua:109: in main chunk
[C]: in function 'require'
spec/items_spec.lua:15: in main chunk
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/block.lua:146: in function 'execute'
/usr/local/share/lua/5.2/busted/init.lua:7: in function 'executor'
/usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/local/share/lua/5.2/busted/execute.lua:58: in function 'execute'
/usr/local/share/lua/5.2/busted/runner.lua:174: in function </usr/local/share/lua/5.2/busted/runner.lua:11>
/usr/local/lib/luarocks/rocks/busted/2.0.rc12-1/bin/busted:3: in main chunk
[C]: in ?
这个问题的答案有一些细节我认为是无关紧要的,但事实并非如此(见我的 )。
特别是,我将模块加载行为的测试与其各种功能的测试分开了。即使 运行 busted -t
以特定测试为目标,被测模块的导入也在两个规范中进行评估;即使 require
调用被放置在根 describe
块的 setup
函数中。
通过合并这两个规范,我能够解决这个双重加载问题。
我目前正在使用 Busted 为 lua mod 库编写单元测试。有问题的文件定义了一个带有一些函数的 module,然后在底部调用其中一个函数来初始化自身。
我发现的问题是 Busted 似乎对所需输入文件进行了两次 lua 处理。
测试
it('does a thing', function()
-- Some setup, replacing globals etc
require('items')
assert.are_equal(2, #Items._registry)
end)
模块
Items = { _registry = {} }
function Items.do_some_stuff() end
function some_util_func() end
function load_registry()
print(debug.traceback())
for i, itm in pairs(Items.do_some_stuff()) do
Items._registry[i] = itm
end
end
load_registry()
如您所见,虽然我简化了代码和名称,但结构并没有什么特别的(据我了解。)
测试总是会失败,因为 #Items._registry
总是 0(并且转储到控制台可以验证这一点)。我尝试在方法内部打印,发现它打印了两次;然后我尝试在那个油膏的顶部使用 debug.traceback
并找到下面的内容。如您所见,堆栈回溯打印了两次,表明代码被 evaluated 两次。
其他人遇到过这种情况吗?我是否针对这种情况构建了错误的测试?或者这是一个错误?
stack traceback:
items.lua:96: in function 'load_registry'
items.lua:109: in main chunk
[C]: in function 'require'
spec/items_pec.lua:50: in function <spec/items_spec.lua:39>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/init.lua:40: in function 'executor'
/usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
...
/usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/local/share/lua/5.2/busted/block.lua:155: in function 'execute'
/usr/local/share/lua/5.2/busted/init.lua:7: in function 'executor'
/usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/local/share/lua/5.2/busted/execute.lua:58: in function 'execute'
/usr/local/share/lua/5.2/busted/runner.lua:174: in function </usr/local/share/lua/5.2/busted/runner.lua:11>
/usr/local/lib/luarocks/rocks/busted/2.0.rc12-1/bin/busted:3: in main chunk
[C]: in ?
stack traceback:
items.lua:96: in function 'load_registry'
items.lua:109: in main chunk
[C]: in function 'require'
spec/items_spec.lua:15: in main chunk
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/block.lua:146: in function 'execute'
/usr/local/share/lua/5.2/busted/init.lua:7: in function 'executor'
/usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/local/share/lua/5.2/busted/execute.lua:58: in function 'execute'
/usr/local/share/lua/5.2/busted/runner.lua:174: in function </usr/local/share/lua/5.2/busted/runner.lua:11>
/usr/local/lib/luarocks/rocks/busted/2.0.rc12-1/bin/busted:3: in main chunk
[C]: in ?
这个问题的答案有一些细节我认为是无关紧要的,但事实并非如此(见我的
特别是,我将模块加载行为的测试与其各种功能的测试分开了。即使 运行 busted -t
以特定测试为目标,被测模块的导入也在两个规范中进行评估;即使 require
调用被放置在根 describe
块的 setup
函数中。
通过合并这两个规范,我能够解决这个双重加载问题。