> > > I hope you're not emulating Test::More's exit code == # of > > > tests failed "feature" that I'm planning on getting rid of. > > > > Right now that's exactly what I'm doing. The test suite for libtap > > consists of a series of Test::More test files and a series of C files that > > try and test exactly the same thing. > > > > For each one of these I make sure that the output from libtap is identical > > to the output from Test::More (modulo differences in reporting which > > file/line a test failed on) and that the exit code is identical. > > I would recommend against emulating this feature. I haven't found it useful > and haven't found anyone who has. It was put in as a very simple mechanism > to determine if your test failed or not without having to parse the output. > This was back when there was no way to run Test::Harness and programmaticly > get the results. > > You might want to throw it in as an option. I'm going to change Test::More > so it no longer mucks with the exit code by default, you'll have to turn > this feature on.
OK. I'll track changes to Test::Harness, and libtap'll stop doing it when T::H stops. Now that there's an effort to separate TAP-the-protocol from T::H, is it worth having an additional mailing list for people who are working on implementing it, test harnesses, and so on, in other languages? Or is perl-qa still the appropriate forum? Whatever happens, I recommend freezing what T::H does now and calling it 1.0, and immediately working on 1.1 which only differs in requiring a non-optional version number to be emitted by a test to indicate which TAP version it's producing. N
