Implementing QuickCheck in Rust: Property-Based Testing

Property-based testing, popularized by QuickCheck, is a powerful technique for verifying software correctness. Instead of providing specific input-output examples, you define properties that should always hold true for your code. This challenge asks you to implement a simplified version of QuickCheck in Rust, allowing you to test your code by specifying these properties and having the system generate random inputs to try and falsify them. This is invaluable for finding edge cases and unexpected behavior that traditional unit tests might miss.

Problem Description

You are tasked with creating a basic QuickCheck implementation in Rust. The core functionality involves generating random data, applying a given function to that data, and then checking if a provided property holds true for the result. Your implementation should include:

Random Data Generation: A mechanism to generate random data of a specified type. You'll need to provide a way to define generators for common types like i32, bool, and potentially custom types.
Property Evaluation: A function that takes the generated data, applies a function to it, and then evaluates a property (a boolean function) on the result.
Falsification: The system should attempt to find inputs that cause the property to evaluate to false. If a counterexample is found, it should be returned.
Iteration Limit: A configurable limit on the number of random inputs generated before giving up.

Key Requirements:

The solution must be written in Rust.
The code should be well-structured and documented.
The implementation should be reasonably efficient (avoiding unnecessary allocations or computations).
The generator should be able to produce i32, bool, and String types.
The property evaluation function should take the input data and the function to be tested as arguments.

Expected Behavior:

The quickcheck function should take a generator, a function to test, and a property function as input. It should return Some((input, result)) if it finds an input that causes the property to fail, where input is the generated input and result is the result of applying the function to the input. If no counterexample is found within the iteration limit, it should return None.

Edge Cases to Consider:

Empty input types (e.g., an empty vector).
Functions that panic or return errors. Your implementation should handle these gracefully (e.g., by skipping the property evaluation for that input).
Properties that are trivially true for all inputs.
Large iteration limits.

Examples

Example 1:

Input:
    Generator: A generator that produces i32 values between -10 and 10.
    Function: A function that takes an i32 and returns its square.
    Property: A property that checks if the square of a number is non-negative.

Output: None (because the property is always true)
Explanation: The generator produces random i32 values, squares them, and the property always evaluates to true.

Example 2:

Input:
    Generator: A generator that produces tuples of two i32 values.
    Function: A function that takes a tuple of two i32 values and returns the first value minus the second.
    Property: A property that checks if the result is less than or equal to 0.

Output: Some((input, result)) where input is something like (5, 7) and result is -2.
Explanation: The generator produces random tuples. The function calculates the difference. The property evaluates to false when the first number is less than the second.

Example 3: (Edge Case - Function Panics)

Input:
    Generator: A generator that produces i32 values.
    Function: A function that takes an i32 and panics if the input is 0.
    Property: A property that checks if the result is always greater than 0.

Output: None (or potentially Some((input, result)) if the generator produces 0 and the property is evaluated before the panic)
Explanation: The function panics when the input is 0. The property evaluation should be skipped for that input.

Constraints

Iteration Limit: The quickcheck function should have an iteration_limit parameter, defaulting to 100.
Data Types: The generator must support i32, bool, and String. You can extend it to support other types if you wish, but these three are required.
Error Handling: The property evaluation function should handle potential panics from the tested function gracefully.
Performance: While not a primary concern, avoid excessive memory allocations or computationally expensive operations within the generator.
Code Clarity: The code should be readable and well-documented.

Notes

Consider using the rand crate for random number generation.
You don't need to implement a full-fledged QuickCheck with advanced features like shrinking. Focus on the core functionality of generating random data and evaluating properties.
Think about how to design the generator to be extensible to support new data types.
The property function should take the input data and the result of the function as arguments. This allows you to make assertions about the relationship between the input and the output.
The quickcheck function should return a Result type to handle potential errors during generation or property evaluation. For simplicity, you can use Result<(), String> where String contains an error message.