On Wed, Jan 10, 2018 at 5:38 PM, Adam Dinwoodie <a...@dinwoodie.org> wrote: >> One disadvantage of this though, if this kind of framework does not >> get popular, then any new test feature must be added at both places >> but it's a waste of time to support both. So... > > I don't follow: if we end up implementing every test twice, as we have > here, then I agree, but I don't think there's much value in doing that > except as a proof of concept, as in this immediate discussion. The > obvious-to-me way to do this would be following the precedent of the > core code: gradually migrate things away from shell code to C code.
Not the tests themselves. Test features, like --valgrind, --debug, --verbose and that kind of stuff. These are handled by test-lib.sh. If we add support for --new-fancy-thing to test-lib.sh then we need some more code in test-lib.c as well. -- Duy
