Clojure 2024调查问卷!中分享您的想法。

欢迎!有关如何使用本站的信息,请参阅关于页面。

+2
测试
已重新分类

现有的clojure.test/use-fixtures函数在处理通用用例时非常有效,但常常发现需要编写仅关联到一组测试的函数,并且不得不将这些测试移动到新的命名空间或手动在测试中扩展环境(fixture)。这些解决方案存在一些问题。

如果是在新的命名空间中

  • 如何命名新的命名空间?我如何确保其他开发者知道在哪里查找它?
  • 将所有关注同一功能的测试拆分,会使整体情况的展望变得困难。
  • 为了避免需要要求其他测试文件,其他常用环境(fixture)需要移动到它们自己的新命名空间。

如果手动拓展

  • 包裹逻辑的包含使得真实测试的关注点变得模糊。
  • 使用多个环境(fixture)进行包裹很繁琐(有很多缩进)。
  • 多个环境(fixture)的重构/排序很繁琐(不像在向量中来回移动符号)。

请求

我非常希望能够有一些机制来将环境(fixture)关联到特定的测试。这已经通过各种社区库(例如,fixakaocha)实现,但这些都倾向于需要使用他们自己定制的clojure.test/deftest实现来绕过功能缺失(fixa)或实现他们自己的钩子系统(kaocha)。

潜在解决方案

  • 遵循fixa的指导,环境(fixture)可以通过元数据附加到deftest上。
  • 可以添加像testing这样的新函数/宏,它接收一个环境(fixture)集合并将它们应用到所有的嵌套deftest。这将依赖于动态变量并在嵌套发生时推入/弹出环境(fixture)

元数据示例

(deftest ^{:fixtures [fixture-a]} some-test
  (is (= 1 2)))

新的宏

(with-fixtures [fixture-a fixture-b]
  (deftest some-test
    (is (= 1 2))))

1 答案

0

被选中了
 
最佳答案
感谢您记录这个,@Alex! 你有兴趣修复补丁吗?
当然,我不记得你是否是贡献者,但 https://clojure.org/dev/dev#_becoming_a_contributor 是这个过程
...