Hi all, Most bugfixes can be accompanied by automated tests. But sometimes, a test for a fix isn't automatable. Maybe it needs gobs of memory, or it's non-deterministic at the margins. Most such tests probably just don't land, effectively memory-holing knowledge that could be useful in the future.
arai and I just created js/src/jit-test/manual-tests/ as a place to dump such tests. Tests I'd put there include tests that: * are unavoidably susceptible to timeouts, * require lots of memory to run (too much for reliable automation, or more than JS developers might want every test-run to temporarily suck up), * are relatively consistent yet could validly fail, in rare case, due to non-determinacy (e.g. Math.random() quality tests), * and probably others. I would *not* land pure OOM-handling tests here, at least not ones based on allocation-counting tactics, as such tests become ineffective at the slightest perturbation to allocation patterns, or the underlying allocator. I expect this isn't a very common need, as most non-OOM fixes can be reliably tested. But this seems much better than just dropping many unusable tests on the floor entirely. Jeff _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
