You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently this is shelling out to prove6, but that's really not necessary. It can just use TAP::Harness directly to run the tests instead. This would also mean you can much more easily inject code into those tests, which may make the implementation of the coverage analysis easier.
The text was updated successfully, but these errors were encountered:
I think, it will lead to incompatibility with some projects.
Firstly, users uses prove6. They configure the project for that. They can use some hack or an unusual nuance for that. Such things will not allow me to do what I want.
Then. Touching tests code is a dirty way. I assume that rococo need to be as less invasive, as possible. It is a clean way. What about easier coverage analysis -- it is not complicated now, I think :)
Then. If user what to use prove or some different way to test, then we will have to work exactly like now.
Finally, I do not see advantages of using TAP::Harness directly in general case. Probably, I'm wrong. @Leont would you describe the concrete advantages of your proposal?
Firstly, users uses prove6. They configure the project for that. They can use some hack or an unusual nuance for that. Such things will not allow me to do what I want.
Then. Touching tests code is a dirty way. I assume that rococo need to be as less invasive, as possible. It is a clean way. What about easier coverage analysis -- it is not complicated now, I think :)
I don't think I understand what you're trying to say. prove6 is really just a CLI wrapper around TAP::Harness. Both mi6 and zef will already use TAP::Harness directly when available, why wouldn't rococo be able to do so as well?
Then. If user what to use prove or some different way to test, then we will have to work exactly like now.
I don't know why anyone would want to use prove (and I'm the maintainer of prove), but there's nothing that prevents you from keeping that as a fallback possible.
Finally, I do not see advantages of using TAP::Harness directly in general case. Probably, I'm wrong. @Leont would you describe the concrete advantages of your proposal?
It's a layer of indirection less, and allows for more control over how the test scripts are called.
Currently this is shelling out to
prove6
, but that's really not necessary. It can just use TAP::Harness directly to run the tests instead. This would also mean you can much more easily inject code into those tests, which may make the implementation of the coverage analysis easier.The text was updated successfully, but these errors were encountered: