Skip to content
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

Closed
Leont opened this issue Jan 27, 2015 · 7 comments
Closed

Experiment with supporting TAP-Y/J #545

Leont opened this issue Jan 27, 2015 · 7 comments
Milestone

Comments

@Leont
Copy link

Leont commented Jan 27, 2015

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.

@exodist
Copy link
Member

exodist commented Jan 27, 2015

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.

@Leont
Copy link
Author

Leont commented Jan 28, 2015

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.

@exodist
Copy link
Member

exodist commented Jan 28, 2015

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.

@Leont
Copy link
Author

Leont commented Jan 28, 2015

I think structured diagnostic should be its own event type.

Agreed.

However the tying of diags to oks probably needs to be made more generic or expandable.

Probably. Haven't looked deeply enough into it. This probably should happen before new T::B becomes stable though.

@exodist
Copy link
Member

exodist commented Jan 28, 2015

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.

@Leont
Copy link
Author

Leont commented Jan 28, 2015

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.

Sounds sensible.

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.

I have no idea what you're talking about, but I'm sure you do.

@exodist exodist modified the milestone: Backlog Mar 23, 2015
@exodist
Copy link
Member

exodist commented May 3, 2016

This can be implemented as a new Test2::Formatter. There is not need to do it in the Test-Simple dist.

@exodist exodist closed this as completed May 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants