Post

When writing about Property-Based testing, I found they were much more solid and comprehensive than usual tests, due to their more general (properties vs examples). They weren’t used because they felt more complex and time-intensive to write, despite being shorter and having to change them less.

3 reposts23 likes

I've read a couple papers on property based testing and the examples are usually very DS&A oriented because it's where testing invariants and defining properties is easy. For business rules it's much more difficult to pin down exact behavior. Requirements might not be precise enough.

Yeah the invariant-based stuff has somewhat low ceilings in what you can do, but stateful properties have an incredible amount of expressiveness for larger scale integration tests around whole workflows that would in theory be very powerful as a backstop for LLM-based development.

my favourite property based testing is Identity diff and patch for example A = diff(B, C) therefore C = patch(A, B) generate a million sets of B and C and you are away obvs there arent always Identities lying around but when there are - did 8m tests at bet365 based on recording and playback

I’m still interested to see how it’ll unfold, but despite shipping code faster and using more general forms of specs when engineering with LLMs, the testing methods used never made use of the gained time nor of the more general spec. Instead the trend is to just generate more examples and review.

I’m not sure what may lie behind these observations, which goals and pressure gradients shape them, but it feels funny/interesting that the gains appear to be “reinvested” in specific ways that reinforce existing tradeoffs, rather than seizing opportunities for a new balance.

Part of it just makes me feel the stuff I wished I could see grow never really mattered to the “group” (see how nobody even looks that way even when there’d be more room now than ever!) and it’s a very funny feeling to contend with. A bit disconcerting to see the distance grow, but better to know?

The other thing might just be a “chop wood, carry water” mindset where you push for what you care for, and rather than aligning with what you see you just multiply your capacity to advance the things you want to see happen. Might be both at once?

I use PBT quite a bit, but I’m always worried that the generator isn’t going to come up with some example I have in my head, so I end up running the property on a bunch of handcrafted inputs anyways

Part of this is that property testing feels magical - the examples are always for things like "assert that is sorted(sort(x))" Which is nice _in theory_, but the docs don't really have much in the way of more complicated examples.

Stateful properties would be so good for the LLM integration flows because they’d even help minimizing context usage. Stateful docs exist (and Anthropic owes me a check for having ingested them), but a problem is that unless the volume is high, it’s hard to amplify these practices via training set.

I think part of the struggle is in this last point: a new practice is possibly harder to push for than before because it is not sufficient to convince and show people locally; you need to do it in a high enough volume to tip the scales of what’s trained and defining baselines at a larger scale.

At some point the property tests I can come up with just feel like some extra ceremony around example tests, but then I lose nice properties like being able to easily debug!

I’d need to show some examples at work, like everything we have that generated extensive scenarios to walk through a release integration scenario could be given as a recipe for it in stateful property tests and have it shrink the failing steps for you.

I suspect the precondition/postcondition/state transition model they have represents a more structured pattern of what people do with agents and steps to validate their work. Turning specs into that sort of test could be very powerful.