Ihor Radchenko <[email protected]> writes: > I think the way the code works is searching the keyword name via > 'member', so the first instance "wins". But this is basically undefined > behavior. Do you really want to test for undefined behaviors?
Well this is where we differ in our expectations of the test-suite. I like to have a reproducible, hands-off method for determining what the current state of the software is. This allows me to make large, sweeping changes and then use the test-suite to see the fallout. I see the test-suite as something to aid in development. I believe you see the test-suite as a promise of how the software should function. You want users to be able to look through the test-suite to see the recommended ways of using the software. I would argue my way of thinking is superior (although I might be biased). Emacs lisp tends to have many layers of indirection (we have some sneaky indirections using text properties) and I often struggle to find all the implications of any given code change. I would much rather have to deal with a test failure that points out a (often unintentional) behavior change I made then try to debug odd behavior from scratch. This is why in the past I have tried to rigorously encodify bugs in the test suite. If the bug gets fixed or the behavior changes, I would really like to know. I suppose in theory this could result in frequent annoying changes to the test-suite, but I doubt that would actually materialize due to the "never break userspace" mentality this project has. And if it ever did become an issue, you could simply remove tests that have a high false positive rate. My education and work experience has 100% indoctrinated me into thinking more tests is always better. I realize that many people seem to push back hard against this mentality but I'm not really sure why.
