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的情况),并用生成复杂度数据(平均时间、尝试次数、规范形式等)填充。它应该以合理的方式来处理过于复杂的规范,即:不是抛出异常(像生成器那样),而是优先报告哪个部分的规范过于复杂以及其元素的个别复杂度。
0

评论者:jare

此外,s/complexity可能应该为每个节点(规范元素)设置超时时间(可能是可配置的),因为它主要是一个调试/分析工具。

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_

实际上,如果允许窥视,它不仅可以用于调试,还可以用于改进性能以改变生成。
为了分摊累积生成器复杂性,通过切换路由来满足某些截止日期。

- - - - -

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

对于


(def g1 ...)

(def g2 (gen/fmap f g1))


复杂度_函数应该输出



(complexit g1) => {:name <generator-name> :time-ms 10}

(complexit g2) => {:name :fmap :time-ms 5 :args [{:name <generator-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 提出)
...