Hacker News Reader

Comment by blt | Hacker News Reader

The article also says:

> ... all the capabilities of reversing events can be done instead by reverting to a past snapshot and replaying the event stream. As a result reversal is never absolutely needed for functionality. However it may make a big difference to efficiency...

When I implemented undo/redo, I found that replaying from snapshots was fast enough. I wasn't working on a database-backed app though.

Implementing reversal is extra work and bug surface, so it should be subject to cost/benefit analysis.

View on HN

I find fuzz testing works great for things like this. Make a function which, given everything you know about a user's state, randomly generates an action that user could take (and the expected result). Then you can run your user model forwards and backwards through randomly chosen actions. If you support undo, check that if you play any change forward then backward, the resulting state is unchanged.

I usually pair that with a "check" function which just verifies that all the invariants I expected hold true. Eg, check the user has a non-negative balance.

It sounds complex, but you get massive bang for buck from code like this. 100 lines of fuzzing code can happily find a sea of obscure bugs.

And if your system isn't using event sourcing (where this sort of testing is relatively simple to add), you can also do model-based testing.

I like this example as a demonstration from FsCheck using F# (for the test program) and C# (for the program under test): https://fscheck.github.io/FsCheck//StatefulTesting.html

If you have any examples of this I'd love to see them. Are you just doing a random pick of X possible actions N times?

We're using jqwik's stateful testing to achieve this, https://jqwik.net/docs/current/user-guide.html#stateful-test...

It's essentially as you described.

Sure - here's a simple fuzzer from a rope (fancy string) library I wrote a few years ago back when I was still learning rust. (Don't judge me!):

https://github.com/josephg/skiplistrs/blob/master/tests/test...

In a loop it simply randomly decides whether to insert, delete or replace some text, and after any action checks that the state is valid (In this case via a call to check2()).

You can go way deeper with this sort of thing if you want, with more complex models, random item generation and simplifiers to help pare down problems to simple test cases. And you can have more complex state - for example, where you also track interaction between multiple items. For example, if your state is a few users, and you also track one user paying another user and verify the total balance across all users is unchanged.

But you don't need to go deep for fuzz testing to be worthwhile. Even something as simple as this little loop is a remarkably effective bug finder.

Reply on news.ycombinator.com