Testing Frankencode has always interested me because absolute testing is essentially impossible. In the 1970’s ‘my work PC’ was a Control Data 175, a supercomputer of the day, and I was taking courses at night. The text was the classic Djikstra’s Discipline of Programming. It was and remains a book from hell with the best messages ever, that have rarely been taken to heart under the pressures of get it done and release it development standards.
Basically and simplistically every algorithm and function should have one entry, one exit, and be mathematically derived as well as mathematically or logically verifiable. Not quite so simple, but mostly that simple. During one memorable class the professor put a short loop on the board and asked the class (mostly professionals, all masters level) how the loop exited. Nobody got it. He explained it. We were embarrassed. I long forget the detail but retained the message.
A reality at the time was shown that to authoritatively test a basic multiplication of any two numbers in the CDC 175 CPU would require many months of 24x7, that being before any other operation or a program was introduced.
Hence what to test and how to test it becomes a field in its own right, and some get it much better than others, but none of it will be or can be authoritative in an absolute sense as a practical matter.
