测试行报告并不总是报告测试的文件及行号

Question

如果在测试执行过程中抛出异常，文件名和行号通常对找出问题帮助不大。例如，以下代码

`
(require '[clojure.test :refer [deftest test-var]])

(deftest foo
(meta))

(test-var #'foo)
`

将在 AFn.java:429 处输出错误。

`
ERROR in (foo) (AFn.java:429)
未捕获的异常，不在断言中。
期望: nil
实际: clojure.lang.ArityException: 传递给 core/meta--4144 的参数数量不正确 (0)
at clojure.lang.AFn.throwArity (AFn.java:429)

clojure.lang.AFn.invoke (AFn.java:28)
user/fn (error_reporting.clj:4)
clojure.test$test_var$fn__7670.invoke (test.clj:704)
clojure.test$test_var.invoke (test.clj:704)
user$eval6.invoke (error_reporting.clj:6)
clojure.lang.Compiler.eval (Compiler.java:6782)
...etc

`

(链接: http://dev.clojure.org/jira/browse/CLJ-377?focusedCommentId=24016&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24016 文本：Rich的评论24016关于CLJ-377) 表示他认为应该报告测试文件行而不是异常抛出的位置。

方法：从错误堆栈跟踪顶部过滤掉堆栈跟踪类前缀 {{clojure.lang.AFn}}。

应用补丁后，以上示例输出为 error_reporting.clj:4

`
ERROR in (foo) (error_reporting.clj:4)
未捕获的异常，不在断言中。
期望: nil
实际: clojure.lang.ArityException: 传递给 core/meta--4141 的参数数量不正确 (0)
at clojure.lang.AFn.throwArity (AFn.java:429)

clojure.lang.AFn.invoke (AFn.java:28)
user$fn__3.invokeStatic (error_reporting.clj:4)
user/fn (error_reporting.clj:3)
clojure.test$test_var$fn__114.invoke (test.clj:705)
clojure.test$test_var.invokeStatic (test.clj:705)
clojure.test$test_var.invoke (test.clj:-1)
user$eval6.invokeStatic (error_reporting.clj:6)
user$eval6.invoke (error_reporting.clj:-1)
clojure.lang.Compiler.eval (Compiler.java:6939)
...etc

`

补丁： clj-1811.patch

Answer 1

评论者：ryfow

描述中的示例文件

Answer 2

评论由：alexmiller发表

在Github上进行快速搜索显示，很多人调用（诚然是私有的）文件和行函数。这些用户将会因补丁而出现问题。或许创建一个新的函数或新的参数类型，而不是移除现有的参数类型会更好。

只是直观判断，但我怀疑你在新代码中的几个地方引入了反射，特别是以下地方可能需要另一个类型提示

1. (.getName (.getClass (:test (meta test-var))))

2. (= (.getClassName %) test-var-class-name)

我需要查看更多代码，才能对自己做出判断。看到测试变量在其中意味着这个函数现在依赖于外部状态，因此需要仔细思考，确保每个调用上下文都有那个全局状态（或者如果没的话，不会以糟糕的方式失败）。在问题描述的“方法”部分看到你对这方面思考的讨论会很有帮助。

Answer 3

评论者：ryfow

第二次尝试修补这个问题。修复了问题（链接：[http://dev.clojure.org/jira/browse/CLJ-1811?focusedCommentId=41115&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-41115](http://dev.clojure.org/jira/browse/CLJ-1811?focusedCommentId=41115&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-41115) 文本：Alex指出的内容）

Answer 4

评论者：ryfow

我在方法部分填写了一些细节。

我还添加了一个新的补丁LINE_REPORTING_2.patch，它解决了反射警告，恢复了{{file-and-line}}的老参数类型，并添加了从测试上下文外部调用{{file-and-line}}的保护。

Answer 5

评论者：ryfow

在和同事James讨论一个问题时，我意识到这个修复有助于共享函数调用{{(is)}}。注意，在应用了LINE_REPORTING_2.patch后，这段代码的运行报告了第7行的错误。这行测试代码通常比共享函数行更有用。

`
ryans-mbp:~/oss/clojure% cat -n error_reporting.clj

 1  (require '[clojure.test :refer [deftest test-var is]])
 2
 3  (defn shared-code [arg]
 4    (is arg))
 5
 6  (deftest test-shared-code
 7    (shared-code false))
 8
 9  (test-var #'test-shared-code)

ryans-mbp:~/oss/clojure% java -jar ~/.m2/repository/org/clojure/clojure/1.7.0/clojure-1.7.0.jar ./error_reporting.clj

在(test-shared-code)中失败 (error_reporting.clj:4)
期望：arg
实际：false
ryans-mbp:~/oss/clojure% java -jar target/clojure-1.8.0-master-SNAPSHOT.jar ./error_reporting.clj

在(test-shared-code)中失败(error_reporting.clj:7)
期望：arg
实际：false
`

Answer 6

评论者：michaelblume

补丁不再适用，但或许CLJ-1856已经解决了这个问题？

Answer 7

评论由：alexmiller发表

CLJ-1856没有解决这个问题，但如果在寻找位置时将clojure.lang.AFn从错误堆栈跟踪中过滤掉，可能会解决这个问题。这非常具体 - 可能有必要将其扩展到其他调用路径，不确定。

附上一个新的补丁，该补丁应用了此筛选。

Answer 8

参考：https://clojure.atlassian.net/browse/CLJ-1811（由ryfow报告）