Summary
Add unit and property-based tests for eql_v3. The current per-variant Rust/SQLx suites are solid integration tests, but they exercise fixed payloads. Property tests would let us assert correctness across a generated input space — e.g. that eql_v2.eq agrees with plaintext equality for any pair of int4 values.
Background
Raised by @coderdan during review of #225 (feat: eql_v2_int4 variant family):
The tests in this file are great as integration tests. I reckon we could consider adding unit and property tests, too.
EQL does not currently have a property-testing harness set up, so this is tracked as follow-up work rather than blocking the PR.
Proposed approach
Use a property-testing crate (quickcheck or proptest) with Arbitrary-derived encrypted-payload structs, comparing SQL operator results against the plaintext oracle. Sketch from the review:
mod eql_v2 {
#[derive(Arbitrary)]
struct Int4Eq {
// -- glossing over details
}
}
// -- a bit approximate
fn sql_compare(a: &Int4Eq, b: &Int4Eq) -> bool {
let response = get_conn()
.query("SELECT eql_v2.eq($1, $2)", &[&a, &b])
.expect("Failed to execute query");
let row = response.first().expect("Expected a result");
row.get(0)
}
quickcheck! {
fn int4_eq(x: eql_v2::Int4Eq, y: eql_v2::Int4Eq) -> bool {
sql_compare(&x, &y) == (x.plaintext == y.plaintext)
}
}
Scope
- Set up a property-testing harness in
tests/sqlx/ (crate choice, Arbitrary impls for encrypted int4 payloads, a DB-connection helper usable from property tests).
- Equality oracle:
eql_v2.eq / eql_v2.neq agree with plaintext == / != for eql_v2_int4_eq.
- Ordering oracle:
<, <=, >, >= (and eql_v2.ord_term sort order) agree with plaintext numeric order for eql_v2_int4_ord / eql_v2_int4_ord_ore.
- Unit tests for edge cases (NULL handling, blocker functions raising, CHECK-constraint rejection of malformed payloads).
- Consider generalising the harness so other encrypted types can reuse it later.
Summary
Add unit and property-based tests for
eql_v3. The current per-variant Rust/SQLx suites are solid integration tests, but they exercise fixed payloads. Property tests would let us assert correctness across a generated input space — e.g. thateql_v2.eqagrees with plaintext equality for any pair of int4 values.Background
Raised by @coderdan during review of #225 (
feat: eql_v2_int4 variant family):EQL does not currently have a property-testing harness set up, so this is tracked as follow-up work rather than blocking the PR.
Proposed approach
Use a property-testing crate (
quickcheckorproptest) withArbitrary-derived encrypted-payload structs, comparing SQL operator results against the plaintext oracle. Sketch from the review:Scope
tests/sqlx/(crate choice,Arbitraryimpls for encrypted int4 payloads, a DB-connection helper usable from property tests).eql_v2.eq/eql_v2.neqagree with plaintext==/!=foreql_v2_int4_eq.<,<=,>,>=(andeql_v2.ord_termsort order) agree with plaintext numeric order foreql_v2_int4_ord/eql_v2_int4_ord_ore.