TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Property-Based Testing in Rust with Arbitrary

89 点作者 jryb超过 2 年前

9 条评论

shepmaster超过 2 年前
Most posts about property-based testing focus on convincing the reader to do property-based tests and the mechanics of writing the tests.<p>Unfortunately, I&#x27;m already convinced and know how to write the tests — what I wish I could find is some resource that would hone my ability to identify worthwhile properties. The best one I know of and go back to time and time again is <a href="https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;posts&#x2F;property-based-testing-2&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;posts&#x2F;property-based-testi...</a>, but I really wish I could find more.
评论 #33555921 未加载
评论 #33555844 未加载
评论 #33557185 未加载
评论 #33557994 未加载
tveita超过 2 年前
It looks like Arbitrary will sample integers from an uniform distribution. For property based testing you often would like to have a bias towards &quot;interesting&quot; values that might trigger special cases, like -1, 0 and 1.<p>E.g. if you had &quot;max_speed_kph: Option&lt;u64&gt;&quot;, your tests might never check what happens if max_speed_kph is 0.
评论 #33559585 未加载
thom超过 2 年前
There are a couple of useful things missing here at a glance. One is shrinking, where the library will attempt to find simpler cases of failures rather than just brute force a random one. Second is how to create related pieces of data that are constrained in some way, above and beyond pure random bytes, but I assume there’s some way here to manually interpret the random bytes. But sometimes you have to hand-tune these things because you don’t just want to wait for the RNG to guess the right combination to create valid data.<p>I’ve had some success with property based testing, at least for heavily algorithmic code. For example I wrote a kNN implementation after finding all sorts of edge cases in others (floating point shenanigans included). You can succinctly capture properties like: returning the right number of clusters, each point being closest to its cluster’s mean, each cluster being centred on its centroid, all points being assigned to a cluster, and all clusters being non-empty. But even then you could game things if you wanted to.<p>Where I’ve struggled is in the general case. Most tests don’t have good property based alternatives, beyond just repeating the logic of the code under test, which seems pointless. And so you have this constant tension of wondering if a particular test could or should be property based.
dmitriid超过 2 年前
The value in property based tests is that the original libraries (Quickchwck, both Haskell and Erlang) try to find the smallest reproducible error sample, and then display that sample to you.<p><i>And</i> that (Quickcheck at least) has a bunch of primitive generators that you build your structures out of.<p>No idea, if it&#x27;s doable in Rust. I just find it strange that it works on a stream of random bytes out of which you magically get some structures.
评论 #33555096 未加载
Rayhem超过 2 年前
Meta question: do many people use property-based testing in their production systems? I think the philosophical idea is extremely sound and is a very good approximation to proving correctness, but I only ever see trivial examples like &quot;a + b = b + a&quot; as a property. How does property-based testing hold up in far larger systems with quite complex setup behaviors?
评论 #33563266 未加载
评论 #33559374 未加载
评论 #33559536 未加载
评论 #33559082 未加载
phamilton超过 2 年前
We use <a href="https:&#x2F;&#x2F;docs.rs&#x2F;proptest&#x2F;latest&#x2F;proptest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;proptest&#x2F;latest&#x2F;proptest&#x2F;</a> extensively at Remind. It very recently got a few new maintainers and does shrinking pretty well.<p>Our biggest use case has been testing our database materialization. We have a somewhat complicated hierarchical organization tree&#x2F;forest within our database. In order to efficiently query those structures, we materialize the transitive closure of these relationships. TL;DR; we populate a row for each (org, ancestor) and maintain that via postgres triggers that fire whenever we mutate things.<p>The prop test that tests it all does three things. First, it establishes an arbitrary that captures all the possible shapes of organization trees. Second, we define the set of mutations (add a child, switch parents, delete a grandparent, etc.) that may occur. Third, we have code for reading&#x2F;writing org trees to and from the DB.<p>The test then generates an org tree, syncs it to the db, performs 1 or more mutations on the tree and then compares what&#x27;s in the database with the resulting tree.<p>Overall it&#x27;s been pretty great. I highly recommend property tests, especially when modeling complex data in an external system.
评论 #33558062 未加载
FridgeSeal超过 2 年前
&gt; I don&#x27;t want From to panic<p>There’s also a TryFrom which returns a Result, in the event your conversions are fallible.
lionkor超过 2 年前
Great name, cant wait to search for arbitrary rust &#x2F;s<p>Just wondering, is there a reason for not having more specific names in rs projects?
WirelessGigabit超过 2 年前
I had a really hard time getting past the bad construction of the struct. Why not make an enum variant where a bike just doesn&#x27;t have a fuel property. Makes things a lot easier.
评论 #33558673 未加载