this post was submitted on 04 May 2026
14 points (93.8% liked)

Programming

26848 readers
520 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] NostraDavid@programming.dev 3 points 4 days ago* (last edited 4 days ago) (1 children)

Canonical should have a look at https://antithesis.com/ - They'll basically run your application in a deterministic VM, where hardware errors are simulated, so you can re-play certain scenarios, not just the happy-path. It should be able to surface bugs way faster than just running into them.

Deterministic simulation testing is what they should be doing.

edit: If you want a demo from the CEO, where he shows off how he tested Super Mario (yes, the NES game): https://www.youtube.com/watch?v=zc4cqtibTzs

Note: These are some guys from FoundationDB, if that means something to you.

Tbh while DST (or just "testing" as hardware people would call it) is very obviously a great idea, I'm not sure it would have helped here - in order to detect these TOCTOU bugs you would need stimulus that triggers it and some kind of checker/model that has the correct behaviour.

That's totally possible but it's pretty hardcore testing for a software project and it's difficult to imagine doing that without realising that you have a TOCTOU issue just by inspection.