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

TAP structured diagnostics #48

Closed
schwern opened this issue Aug 28, 2010 · 5 comments
Closed

TAP structured diagnostics #48

schwern opened this issue Aug 28, 2010 · 5 comments

Comments

@schwern
Copy link
Contributor

schwern commented Aug 28, 2010

Output TAP structured diagnostics.

not ok 1 - foo

---
have: foo
want: bar
line: 42
...

JSON and YAML should be supported both human readable and minified.

Human readable comments to STDERR should still happen unless explicitly turned off or it can make a reasonable guess that the harness understands diagnostics and is producing its own messages.

Look into the "info" branch for implementation to steal.

@schwern
Copy link
Contributor Author

schwern commented Sep 10, 2010

@schwern
Copy link
Contributor Author

schwern commented Sep 10, 2010

This is being implemented in TB2-TAP-structured-diagnostics

@schwern
Copy link
Contributor Author

schwern commented Sep 10, 2010

At the start, its fine to use an existing YAML and JSON library. Later, we'll probably copy in YAML::Tiny or JSON::Tiny or the YAML emitter used by MakeMaker to do META.yaml which specializes in making things look pretty.

@notbenh
Copy link

notbenh commented Sep 10, 2010

Taking a look at the spec, does the result normally get the have/want/file/line stuff? or is that something else that the Formatter needs to dig up else where. In the tests we've been building up result objects on the fly so they are non-standard with the're payload.

@schwern
Copy link
Contributor Author

schwern commented Sep 11, 2010

Be aware, the spec has some bit rot.

have/want/file/line are all optional, the spec just provides some standard key names to use for those concepts. If they're in $result->diagnostics, use them. If not, don't. You should already see this with the way the TAP::v13 formatter builds up its failure comment.

You'll probably find that having $result->diagnostics contain an array is cumbersome. The idea was to preserve order and the same key being set multiple times, but I really don't think that's important. Feel free to change it to a hash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants