如何在Clojure中对副作用函数进行单元测试?

时间:2015-11-18 09:11:31

标签: unit-testing testing clojure side-effects core.async

这个问题不是关于特定的库(尽管其中一些将被最终使用),但更多的是关于如何构建应用程序代码以使副作用函数单元测试成为可能。如果我们应该这样做?

显然,测试纯副作用自由函数是明确而简单的,你传递输入,然后断言输出。

有2种(非常粗略)类型的测试,单元和集成。让我们专注于单元测试。

因此,如果您有一个从文件读取或写入文件的函数(例如,使用spit / binding),或者使用数据库,响铃应用程序或core.async通道,如何在Clojure中对这些东西进行单元测试?嘲笑是否涉及,如果是,应如何定义?是否涉及with-{redefs, redefs-fn, local-vars}defprotocol?我应该定义Rack::Lint以便在单元测试期间实现(也就是模拟?)实现吗?

测试的价值之一(主要值?)是强制对应用程序代码进行更好的设计,所以Clojure中的测试在这个意义上可能是特殊的,你被迫以特定的方式构造应用程序代码可以在Clojure中进行副作用功能单元测试吗?

或者我完全错过了这一点?

P.S.1:我很乐意使用Clojure中小型应用程序进行工作和开发(当然还有一段路要走),尽管测试部分仍然不完全清楚。

P.S.2:另一个重要的主题是Clojure中的集成测试,但它应该得到一个单独的SO问题。

2 个答案:

答案 0 :(得分:1)

通常,您测试具有副作用的代码是为您的测试实现设置和拆卸工件。这些创建基本/初始状态并帮助评估结果。

答案 1 :(得分:1)

我强烈建议您尽可能避免protected void btnLuu_Click(object sender, EventArgs e) { ….//save your data //if save successful Response.Redirect("Default.aspx?Module=" + cModule + "&l=" + language_id + "&p=" + p + "&alert=success"); } 和朋友。我们使用协议进行大多数与外部服务的交互,并在各处依赖注入,因此测试是轻而易举的。当然,我们仍然尽量使功能尽可能纯净并仔细管理效果,但通常我们在需要时对协议感到满意。