Andriy Palamarchuk apa3a@yahoo.com writes:
Could you, please, list the additional features we need? I'll try to estimate amount of work necessary to implement them in Test::Harness.
Basically the features I get with my 10-line makefile hack: ability to run tests for modified dlls and their dependencies (for instance if you change something in user32 and run make test it doesn't run tests for kernel32), ability to remember which tests failed and run only these the second time around, trivial integration of new tests (just add one line in a makefile).
Do you want to use architecture, completely different from Test::Harness + Test::Simple modules or you only want to replace Test::Harness?
I think we would be much better off developing a simple infrastructure from scratch that does exactly what we want, than trying to bend an existing framework to our needs. This will also ensure that the framework remains as simple as possible, which is important since every extra feature, even one we don't use, can possibly introduce problems (like the pipes/fork issues have shown).
Does this output look closer to the one you want? Let me know if you need any other information.
I don't really care about the output. My point is that this output is not necessary, a simple "assertion foo failed at line xx" on failure and no output at all on success would work just as well. I've nothing against such an output either, but I don't think it justifies introducing the complexity of reusing the Test stuff.
Sorry, misinterpreted your statement that threads won't be used for tests in Perl. Could you give your vision when C is used?
In my vision we either use Perl everywhere, or C everywhere. If we use Perl there may be a need for a few little glue programs in C, but this doesn't require any C infrastructure.
I personally think Perl would be a better choice, but I seem to be pretty much the only one of this opinion. In any case the most important thing is to choose something that people are going to use, and so far the Perl stuff isn't a success in this respect. I'm not convinced a C infrastructure would fare better, but maybe we should try it and see.