Hi, Jim; Further to that point, simply reaping the exit code of zero or non-zero should be enough for a test to communicate success or failure.
My only concern with this concept is that it could make our testing framework require a *very* unique set of system libraries, binaries and interpeters to be installed to run the full suite of tests. For a strawman example, I don't have nodejs on my Linux testing machine (easily fixable), but it doesn't seem clear if AIX is supported by nodejs (maybe not fixable?). Other languages like golang are in the same boat. Maybe we could have the test framework inquire with the script/binary if the execution environment can run the test before executing the test itself? The other thing I wonder about is how difficult it will become to maintain the tests since some concerns with the current framework's language have already been expressed. For its faults and virtues, at least the test framework is in a single language. I suspect most of us can figure out what other languages are doing, so maybe it's not a big deal... WDYT? -- Daniel Ruggeri On April 24, 2018 7:50:18 AM CDT, Jim Jagielski <j...@jagunet.com> wrote: >One idea is that we setup, using the existing perl test framework, a >sort of "catch all" test, where the framework simply runs all scripts >from a subdir via system() (or whatever), and the reports success or >failure. Those scripts could be written in anything. This would mean >that people could add tests w/o knowing any Perl at all. It would >require, however, some sort of process since those scripts themselves >would need to be universal enough that all testers can run them. > >I may give that a whirl... I have some nodejs scripts that test >websockets and I may see how/if I can "wrap" them within the test >framework.
