奖励发放函数内部直接调真邮件接口,测试"满 100 级发裁决之杖"这条用例时,每跑一次就有一封真邮件发到玩家信箱——测试代码在生产数据上留痕,测试越充分污染越重。依赖注入封装:函数不自己找依赖,邮件接口从参数传入,生产装配真接口、测试装配记录器,同一段业务逻辑两套环境零改动复用。
依赖注入的发放器与双环境装配:业务收依赖、装配定环境。示例代码如下:
local function createRewardSender(mailFn)
return function(actorName, itemId, num)
if itemId == "" or num <= 0 then
return false, "参数不合法"
end
return mailFn(actorName, itemId, num)
end
end
-- 生产装配:真邮件
local prodSender = createRewardSender(function(actorName, itemId, num)
sendmail("#" .. actorName, 0, "奖励发放", "请查收附件。", itemId .. "," .. num)
return true
end
)
-- 测试装配:只记录不发
local testLog = {}
local testSender = createRewardSender(function(actorName, itemId, num)
testLog[#testLog + 1] = { to = actorName, item = itemId, num = num }
return true
end
)
同一业务逻辑跑测试用例示例代码如下:
local ok = testSender("无名小卒", "裁决之杖", 1)
assert(ok and #testLog == 1 and testLog[1].item == "裁决之杖")
createRewardSender 是高阶函数:收邮件函数、返回业务函数——业务只管调用注入进来的 mailFn,不关心它是真邮件还是记录器。生产装配在入口处完成一次,测试装配在用例里按需构造;testLog 让断言直接核对"发了什么、发给谁、数量多少",不需要查库验证。业务函数内部的参数校验照常生效,测试环境同样覆盖非法参数分支。
依赖注入踩过三个坑:一是注入面过宽——把整个邮件模块当依赖传入,测试断言时要 mock 十几个函数,颗粒度失控;依赖应注入"业务用到的最小接口"(本例只需一个发信函数);二是函数体内留了默认兜底(mailFn 为 nil 时自动用真接口),测试忘了注入就静默发真邮件,兜底反而制造事故,依赖缺失应当场报错;三是模块级单例持有依赖(加载时固化 prodSender),后装配的测试依赖进不去,依赖的装配点必须晚于使用点、由入口统一装配。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
一、抛坑提问:三方增强插件直接 getmetatable(weapon) 拿到元表,把裁决之杖攻击改到 9999。元表能不能…
一、一行代码拆解:rawget(PriceList, name) —— 这一行绕过元表直达表本体,价目查询不走 __inde…
一、隐蔽陷阱:沙巴克守城名单清理离线成员,正序 for 循环里 table.remove(list, i),删一个后续整体前…
一、线上事故:运营要按供需公式浮动裁决之杖价格,某次把表达式字符串直接塞进裸 loadstring 执行,串里夹带未知全局调…
一、线上事故:红名洗白进度按 10 段槽位刷新,GM 修正过 PK 值的玩家带着 -8 的负值进来,进度槽算出 -2,进度条…
一、抛坑提问:烈火剑法连招表存着 4 段延时 {200, 400, 600, 900},算总窗要逐个相加。段数扩到 6 段,…