New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experiment with supporting TAP-Y/J #545
Comments
I am in support of this, and will do anything I can to help someone who wishes to do it. That said I am afraid I lack the time to do it all myself right now. If someone tells me they want to do it I would be happy to give them github access to the project for the purpose of creating a branch for any changes they feel are necessary or helpful to complete the module. |
I suspect it may require some amendment to the way Test::More::Tools and Test::Event::Context communicate diagnostics, but I haven't looked deeply into it. |
I think structured diagnostic should be its own event type. Trying to hack the existing diag object to do what it does now and new stuff sounds unnecessarily complicated. However the tying of diags to oks probably needs to be made more generic or expandable. |
Agreed.
Probably. Haven't looked deeply enough into it. This probably should happen before new T::B becomes stable though. |
I think the answer here is for ok to accept any event type (except other oks) as diag. If it gets a string it does what it currently does and turns it into a diag. Objects remain objects, nothing else is accepted. This let's you provide any event type you want as a diagnostic. The fact that context auto-sends generated events is a problem in this regard, so that design needs to be reconsidered. Either make the events not autosend, or have a new_EVENT method for all event types. |
Sounds sensible.
I have no idea what you're talking about, but I'm sure you do. |
This can be implemented as a new Test2::Formatter. There is not need to do it in the Test-Simple dist. |
TAP-Y/J is a new testing format that's apparently popular in Ruby-land. I'm not particularly fond of it, but writing a TAP-Y/J backend would be a good test of whether the new Test::Builder can expose structured diagnostics well enough, even if we might not want it to be part of the main dist.
The text was updated successfully, but these errors were encountered: