adrigzr / neotest-mocha

Neotest runner for Mocha test framework
10 stars 9 forks source link

Allow passing to or generating arguments for mocha command invocation #12

Closed MisanthropicBit closed 7 months ago

MisanthropicBit commented 9 months ago

Hi, it's me again 😅

I've been trying to get mocha to output test results to both a json file and the console. Currently, neotest-mocha invokes the json reporter which lets neotest generate results but that means that the ordinary test output printed to the console (by way of the 'spec' reporter) isn't available so if a test fails, there's no way to tell why other that running the test from the command line or inspecting the temporary, generated json file.

To solve it, I've created a third party reporter similar to this and this and fixed a few issues. I've tested it on a large project by changing how neotest-mocha invokes the mocha command and it seems to work 🙂

It would be great if I could instead pass my desired arguments when setting up neotest-mocha. I was thinking of either passing an array of strings or a function that accepts the results_path and testNamePattern or a context table (a bit more future-proof) so the user can generate the command arguments per mocha invocation. I've given an example of my "hack" setup below to better convey the idea. Would you be open to accepting a PR for this? Any thoughts on the setup?

require("neotest-mocha")({
    command = "npm test --",
    command_args = function(results_path, testNamePattern)
        return {
            "--full-trace",
            "--reporter=mocha-multi-reporter",
            "--reporter-options=reporters=spec:json",
            "--reporter-options=json:output=" .. results_path,
            "--grep=" .. testNamePattern,
            "--colors",
        }
    end,
    cwd = function()
        return vim.fn.getcwd()
    end,
})
MisanthropicBit commented 8 months ago

As a good use case, I have a project where there are both ordinary unit tests and database integration tests which are invoked using different package scripts and thus differ in package script name. They also differ in arguments so the above addition would be very flexible for allowing the user to run different scripts and arguments as necessary. One could pass the path to the command_args function as well as is done with the command option.