Hit the nail on the head. For same reason requirements writing is so difficult, to explain every edge case you end up writing the whole software again, using hu

Hit the nail on the head. For same reason requirements writing is so difficult, to explain every edge case you end up writing the whole software again, using human language. Writing software is the process of explaining a set of conditions and conversions from input to output. We should assume the programmer does this in as short code as possible (unless we are using a low level language like C which adds a lot of accidental complexity like memory management). To repeat all these conditions in test-code, would be to write the same thing twice, in a different way. Not saying this is wrong, it's just important to acknowledge it. Testing often becomes more like sampling, with hard coded or generated known set of inputs/outputs, often taken from a scenario derived from a common user journey. This verifies that this particular journey works, but it would never be a guarantee that other edge cases of it does, to do that you do end up in the write-twice situation.