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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: Allow passing in a "target object" for the JSON reporter #5111

Open
3 tasks done
JoshuaKGoldberg opened this issue Mar 4, 2024 · 1 comment
Open
3 tasks done
Labels
area: reporters involving a specific reporter status: in triage a maintainer should (re-)triage (review) this issue type: feature enhancement proposal

Comments

@JoshuaKGoldberg
Copy link
Member

Feature Request Checklist

Overview

Filing an issue for #4822, as described by @ashleyfrieze in #4822. The summary is that in some test setups it's not feasible to have Mocha output to a file.

The use case that drove this is where I'm using mocha as the test framework, running it in a virtual browser, driving the tests from a Java application and need to gather the test results from Mocha. I don't have the ability to send them to a file from this environment, but being able to put them into a variable means I can pull the results out at the end.

In particular, I was running mocha inside a Java test. The sut code in question was the embedded javascript being served by the Java application server as part of its SSR. The project, though a Java project, essentially had some JavaScript in it, and wrapping a mocha test within a JUnit test runner required the mocha tests to be executed, but the test runner to be able to acquire the results at the end.

Suggested Solution

Add to the existing configuration options for the JSON reporter by allowing a target object to be provided to be populated with test results.

Alternatives

We could make a duplicate of the JSON reporter, purely for writing to objects. A workaround is to hack in an alternative of the JSON reporter into the reporters in the runner. However, this is such a small addition to the core, and entirely in keeping with the behaviour of producing a JavaScript model of the test results, that it seems to belong in core.

Additional Info

It's a nice to have feature, and pretty innocuous. I worked around it somehow in my project, but could imagine coming back to this and wanting it in future Java SSR situations, or in situations where some mocha tests are being run by a different test framework as part of a transition plan.

See also previous PR: #2651.

@JoshuaKGoldberg JoshuaKGoldberg added type: feature enhancement proposal area: reporters involving a specific reporter status: in triage a maintainer should (re-)triage (review) this issue labels Mar 4, 2024
@JoshuaKGoldberg
Copy link
Member Author

JoshuaKGoldberg commented Mar 4, 2024

Now looking at this from the perspective of a maintainer: I'm of the opinion this isn't worth the maintenance cost to include in core.

Having an object that receives properties doesn't work well with how existing reporter options are set up. Reporters generally have options that can also be specified in config file and/or --reporter-option on the CLI. This new option as implemented in #4822 would only be reasonably useful with programmatic usage, right? (did I misinterpret it?)

Another couple alternatives could be to...

  • ...make a temp file on disk - which should be doable for most consumers
    • I do question why that wouldn't be doable, if you're already in an environment that can run tests?
  • ...run Mocha in a process with stdout parsed and captured in an object
    • Admittedly, that's a little clunky and has some overhead...

IMO a better path might be to make a community fork of the reporter. If that fork ends up getting a lot of usage then we can consider that evidence to build this feature into core.

cc @mochajs/maintenance-crew for more thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: reporters involving a specific reporter status: in triage a maintainer should (re-)triage (review) this issue type: feature enhancement proposal
Projects
None yet
Development

No branches or pull requests

1 participant