proptest
trust
Our great sponsors
proptest | trust | |
---|---|---|
15 | 1 | |
1,554 | 1,238 | |
3.2% | - | |
8.3 | 0.0 | |
7 days ago | over 1 year ago | |
Rust | Shell | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
proptest
-
What Are The Rust Crates You Use In Almost Every Project That They Are Practically An Extension of The Standard Library?
proptest: Property-based testing with random input generation.
-
Iterating on Testing in Rust
Isn't proptest something that could handle this?
-
The birth of a package manager [written in Rust :)]
proptest is great! It generates random input data according to some rules, and if the input fails it saves random seed into a file so that failing inputs are guaranteed to be tested on the subsequent runs (as well as new random inputs). It also doesn't immediately stop on fail but tries to find a minimal failing input first.
-
Hey Rustaceans! Got a question? Ask here (11/2023)!
The only other crate I could find is proptest, but it looks a lot more complicated, and I don't know if lets you skip the shrinking step as quickcheck does. I've been reading the book and going through the docs, but a quick answer would be appreciated.
-
Hey Rustaceans! Got a question? Ask here! (32/2022)!
Hi, I'm working on a fuzzer, that fuzzes APIs based on OpenAPI specification. I'd like to implement shrinking. It means that when an interesting input (for the API) is found, I'd like to create the smallest possible input that still causes the same behaviour of the API. I'd like to implement a payload generation via proptest, because it already has the shrinking ability. I'm having issues implementing the JSON object as a proptest strategy. Here is what I tried so far. I explained it in a detail in stackoverflow question but it did not reach many people. Thanks for your help!
-
Which Mutex to use in this case (independent tasks, partially under contention)
Third, if you're opting out of a compile-time safety guarantee in the name of performance, test heavily (high-coverage unit tests, property testing, fuzzing, differential fuzzing, etc.) and make use of tools like Loom and Miri's runtime data race detector for unsafe code, which can catch stuff that is beyond the scope of the compiler's guarantees.
-
Is RUST aiming to build an ecosystem on scientific computing?
See also property testing
-
Is there a rust way for doing TDD?
It is not hard to do TDD with integration tests either, just write tests that encapsulate the properties you want your library to hold then implement those properties one by one. This is also known as property driven/based testing which then couples well with fuzzers or randomized testing where you randomize the input rather than using large amounts of test assets. This also help you catch a lot more bugs that you never even thought of. proptest is a good library that can help with this.
- Go Fuzzing
-
In praise of property-based testing (2019)
I'm quite new to property testing, first introduced recently via a Rust property testing framework proptest[0]. So far i've had the feeling that property testing frameworks need to include a way to rationalize complexity, as their assumptions can easily fall short as you illustrated.
Eg the simplest example might be an application where you input an integer, but a smaller int actually drives up the complexity. This idea gets more complex when we consider a list of ints, where a larger list and larger numbers are simpler. Etcetc.
It would be neat if a proptest framework supported (and maybe they do, again, i'm a novice here) a way to rank complexity. Eg a simple function which gives two input failures and you can choose which is the simpler.
Another really neat way to do that might be to actually compute the path complexity as the program runs based on the count of CPU instructions or something. This wouldn't always be a parallel, but would often be the right default i imagine.
Either way in my limited proptest experience, i've found it a bit difficult to design the tests to test what you actually want, but very helpful once you establish that.
trust
-
I made a Rust CLI tool for migrating Jekyll blog posts to a Gatsby website
It's published on cargo and can be installed from there, I've also been trying to use [trust](https://github.com/japaric/trust) to automatically generate binaries in CI for people to install, although the deployment isn't working yet.
What are some alternatives?
quickcheck - Automated property based testing for Rust (with shrinking).
afl.rs - 🐇 Fuzzing Rust code with American Fuzzy Lop
tarpaulin - A code coverage tool for Rust projects
Mockito - HTTP mocking for Rust!
Clippy - A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/
stainless - Organized, flexible testing framework for Rust
polish - Testing Framework for Rust
WoeUSB - A Microsoft Windows® USB installation media preparer for GNU+Linux
Mockiato - A strict, yet friendly mocking library for Rust 2018
just - 🤖 Just a command runner