Hellandizing (1998)

Me too. Example find involves stacks. I always hated things like stack canaries. I said they should just fix the problem of data flowing toward stack pointer. MULTICS had a reverse stack. Overflows dropped into newly allocated memory. Makes much more sense...

Realize that this was also for Tandem - makers of the "Non-Stop" systems with 5 9's reliability (these machines incorporated such things that you could upgrade the ram while it ran, pull things out and it would keep going - even a cpu, etc - it used redundancy and a variety of other special stuff in the OS and was pretty lengendary). Which might explain some of the strange things this kind of testing system can do (ie - crash the CPU).

I don't think for most regular systems that this is what the world of testing looked like in the 90s (definitely not from my perspective at the time - I was neck-deep in a VB5 project then).

This does seem like an interesting method of testing, though, for those Tandem systems. I'm not sure if those systems are still available today, but I wouldn't doubt that there are examples still running (likely banking/financial sector - where IIRC is where they were mostly used).

For certain kinds of code, this approach is the only way you can create unit tests that mean anything, so it's kind of orthogonal to TDD.

Nah that would be Cleanroom, Eiffel Method, or Praxis-s Correct-by-Construction if it's an alternate history focused less on testing. Cleanroom and Praxis got defect rates under 3 per Kloc with either money saved or 30-50% extra cost.

http://infohost.nmt.edu/~al/cseet-paper.html

https://www.eiffel.com/values/design-by-contract/introductio...

http://www.anthonyhall.org/c_by_c_secure_system.pdf

TDD is a bit of a red herring here - it's just a technique more suitable for some things than others. It cannot, by it's very nature, effectively replace many other techniques no matter how much one might wish it so.