Deterministic simulation testing for a word processor

> So, was writing Lincoln worth it? Absolutely yes. I am actually surprised with how effective this very humble script has been already. When I first got Lincoln working properly, it immediately uncovered two bugs which caused eno to crash.

"Attempting to prove any nontrivial theorem about your program will expose lots of bugs: The particular choice of theorem makes little difference!" --Benjamin Pierce

I am really glad to see that deterministic simulation testing is getting more coverage on HN lately. It feels like the next step up from property-based testing and (coverage-based) fuzzing.

We have gotten a lot of good use out of property-based testing in Haskell (using QuickCheck) since it is easy to set up and can cover a lot of ground for which you would otherwise have to write a lot of testing code.

I think that techniques like this have the potential to dramatically change software for the better if more of our industry starts adopting them (and it feels as if this is happening more and more!).

Deterministic simulation testing, property based testing, etc. are very exciting to read about and learn.

Although I consider myself someone that likes to test and ensure correctness it’s only this year that I’ve been using property based testing, and it’s such a… pleasant (?) and very underrated testing methodology. I simply can’t imagine not using it now.

I’ve been working on a project involving maze generation and solving and I’m able to rapidly test something that otherwise would have required a lot of manual fixture creation and lots of test data.

Now I’m able to hit edge cases I didn’t even think of before and with less test data.