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
{{ message }}
Repository navigation
<
8000
div class="prc-PageLayout-Sidebar-iciWg" data-component="SplitPageLayout.Sidebar" style="--spacing:var(--spacing-none);--pane-min-width:450px;--pane-max-width:768px;--pane-width-custom:544px;--pane-width-size:var(--pane-width-custom);--pane-width:544px">
Feature-request: ability to adjust output format #13
It would be great to have the choice between multiple output formats (comma-separated, newline, ...) and/or the ability to replace formatDetails at all.
@WolfgangKluge Thanks and so sorry for my late response. Would you tell me example of formats that you want to use? I'm ok to reveal formatDetails method but I want to see the real usage before that.
I tried to use your library with a tap consumer (testem). This consumer needs a somewhat different format. The solution could be on both sides - but in this case I think testem is mainly right.
The main thing is, that lines starting with # are treated as comments. Thus
# Test name
ok - assertion name
just ignores the test name on the consumer side. (If I remember correctly) it's even worse if I don't provide an assertion name. Then I'll get something like
ok - okay
I've a similar problem with multiline text (only the first line is readable to non-humans) and well known metadata like expected, actual, and stack (it's not distinctable anymore).
I would expect something like this (if you prefer one ok/not ok-line per assertion)
ok - module name - test name - assertion name 1
ok - module name - test name - assertion name 2
not ok - module name - test name - assertion name 3
---
actual: 2
expected: 3
stack:|
multiline
text
...
or one ok/not ok-line per test
ok - module name - test name 1
not ok - module name - test name 2 - first failing assertion name
---
actual: 2
expected: 3
stack:|
multiline
text
...
If I can achieve such formats by overwriting formatDetails it will be great - it would be even better if you'll provide different output formats 😁
Activity
twada commentedon Feb 21, 2017
@WolfgangKluge Thanks and so sorry for my late response. Would you tell me example of formats that you want to use? I'm ok to reveal
formatDetailsmethod but I want to see the real usage before that.WolfgangKluge commentedon Feb 21, 2017
@twada: Thanks for answering...
I tried to use your library with a tap consumer (testem). This consumer needs a somewhat different format. The solution could be on both sides - but in this case I think testem is mainly right.
The main thing is, that lines starting with # are treated as comments. Thus
just ignores the test name on the consumer side. (If I remember correctly) it's even worse if I don't provide an assertion name. Then I'll get something like
I've a similar problem with multiline text (only the first line is readable to non-humans) and well known metadata like
expected,actual, andstack(it's not distinctable anymore).I would expect something like this (if you prefer one
ok/not ok-line per assertion)or one
ok/not ok-line per testIf I can achieve such formats by overwriting
formatDetailsit will be great - it would be even better if you'll provide different output formats 😁twada commentedon Feb 23, 2017
Thanks and understood. You are be talking about TAP 13 specification.
I'm willing to provide options like
showTestNameOnSucess(easy enough)showModuleNameOnFailure(easy enough)tapSpecVersion(a bit difficult)If you are in a hurry, please override entire
tap.logmethod.Thanks!