8000 Feature-request: ability to adjust output format · Issue #13 · twada/qunit-tap · GitHub
[go: up one dir, main page]

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

Open

Description

@WolfgangKluge

It would be great to have the choice between multiple output formats (comma-separated, newline, ...) and/or the ability to replace formatDetails at all.

Activity

  1. twada commented on Feb 21, 2017

    @twada
    Owner

    @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.

  2. WolfgangKluge commented on Feb 21, 2017

    @WolfgangKluge
    Author

    @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

    # 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 😁

  3. twada commented on Feb 23, 2017

    @twada
    Owner

    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.log method.

    var tap = qunitTap(QUnit, function() { console.log.apply(console, arguments); });
    tap.log = function log (details) {
        tap.count += 1;
        var testLine = details.result ? 'ok' : 'not ok';
        testLine += (' ' + tap.count);
        testLine += (' - ' + details.module);
        testLine += (' - ' + details.name);
        testLine += (' - ' + details.message);
        tap.puts(testLine + ' ### your YAML block here ###');
    };

    Thanks!

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0