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

欢迎!请参阅 关于 页面了解有关此功能的一些更多信息。

0
test.check
如果生成器输出的值包含尝试和时间的元数据,这可以对生成测试(带有规范)进行优化非常有用。
示例

(-> (s/exercise string? 1)
    first
    meta)
;; => {:time-ms 2, :attemts 1}

这可以帮助找到最慢的生成器,这些生成器最有益于定制。

12 个答案

0
_由 alexmiller_ 发表评论

我将此移动到 test.check,因为生成器就在那里。

请注意,并非每个值都可以携带元数据(数字、字符串等),但这是一个有趣的想法。
0
_由 jare_ 发表评论

> 注意,并非每个值都可以携带元数据(数字、字符串等),但这是一个有趣的想法。

由于元数据将主要用于递归/嵌套规范的工具程序开发者,这对他们来说不是什么大问题。任何希望使用它的人可以通过包装基本类型来解决这个问题。

对于最终用户的 API,类似于 spec/explain(s/explain-data, s/explain-str..) 的东西将很棒。
我将称之为 s/complexity,该函数接受一个规范并将返回与原始规范相同形状的结构(对于 s/complexity-data)(平均时间、尝试次数、规范形式的 mb...)。它应该以合理的方式处理过于复杂的规范,即而不是抛出(与生成器类似),最好报告规范哪一部分过于复杂以及其元素的个人复杂性。
0

评论者:jare

还应该为每个节点(spec元素)可能设置一个超时(可能是可配置的),因为这是一个主要用于调试/性能分析的工具。

0

评论者:gfredericks

这里的“尝试”是什么意思?它仅适用于 {{gen/such-that}} 生成器吗?

0

评论者:jare

是的,在规格说明的上下文中。生成器为了满足规格必须重试多少次。

0

评论者:gfredericks

我刚刚注意到这个 {{:time-ms}} 特性,这应该适用于比 {{such-that}} 更多的情况。

我同意能够轻松地调试生成器的性能是有用的,但我觉得这种策略如何应用于某些组合器,例如 {{gen/fmap}} 和 {{gen/bind}} 并不是很明显。如果在更具体的建议中包括这些情况的细节,我会更容易考虑。

0

评论者:jare

bq. 但我觉得这种策略如何应用于某些组合器,例如 gen/fmap 并不是很明显。

元数据不应该是从 {{gen/fmap}} 应用在的函数中获得的。相反,函数内的花费时间和其他性能统计信息应该与 {{gen/fmap}} 输入统计信息相关联,然后与输出一起返回。这样数据将在嵌套 {{gen/}} 调用之间通过上下文传递。

bq. 元数据不应该是从 {{gen/fmap}} 调用的函数中获得的。

或者,您可以允许查看输入统计信息但不要更改它。不确定是否这样。可能太复杂了。

0
_由 jare_ 发表评论

实际上,如果您允许窥视(Peeking),那么它不仅可以用于调试,还可以用于性能优化而生成的更改。
为了摊销累积生成器的复杂性,通过切换路由来满足某些截止日期。

- - - - -

@gfredericks 由于某种原因,我无法向任何问题添加新评论,所以我更新了旧的一个。

对于


(def g1 ...)

(def g2 (gen/fmap f g1))


复杂性_函数应输出



(复杂性 g1) => {:name :time-ms 10}

(复杂性 g2) => {:name :fmap :time-ms 5 :args [{:name :time-ms 10}]}


这里 _:time-ms 5_ 是在 _f_ 函数内花费的时间。
0

评论者:gfredericks

例如,假设我有

`
(def g1 ...)

(def g2 (gen/fmap f g1))
`

当我从 {{g2}} 生成一个值时,我会得到什么信息?这将关于 {{g1}},还是关于 {{f}},或者是两者之间的一种?

0

评论者:gfredericks

(链接: ~JAre) 我相信您的评论权限已修复。

好吧,我可以看到这可能是明确定义的概念。但这需要相当多的工作量,并且我想要确保不会有重大的性能差异。如果有的话,我们可能需要一个默认关闭它的方式,并确保关闭时性能没有受到影响。

0

评论者:jare

是的,现在可以工作了。谢谢。

0
参考: https://clojure.atlassian.net/browse/TCHECK-153 (由 alex+import 报告)
...