busted
busted copied to clipboard
lunarmodules
run busted as inline lua
the only way (that i can see) to run busted tests is via 'busted.runner'. And it MUST be run from the cli because it expects to parse arguments using 'term'
It would be great if you could invoke busted inline as part of a lua file. This is useful for writing integration tests for lua code that runs on a framework. You want have access to the APIs exposed by the framework for integration tests. As a result you cant invoke via the busted CLI wrapper
MyFrameworkBustedTestRunner
-- configure the framework as needed for the tests
-- run busted tests
busted.run(busted_config_options)
please let me know if there's a way to do this. The project is composed in a way which makes it seem feasible, but i cant pinpoint a good entry point
:+1:. I'm looking to run tests as part of a larger suite of tasks inside one Lua process, and I can't figure out the correct way to do so. I think it involves duplicating most of the runner code but without the CLI wrapper, but I'm not entirely sure.
Right now there's no documented way for you to do this.
...but, if you just require busted.core, manually set up the options you would like just like busted.runner does, and publish the appropriate events so the output handler knows what's up, it should work for your use case just fine. If you'd like to make that process generic we'd welcome a pull request!
Thanks for the direction. Much of the loader code depends on penlight LFS based apis, which may not work depending on how the lua env is hosted. Are you suggesting that we would need to implement our own loaders as well as handlers?
As an example, lua is embedded in something that does not expose a traditional filesystem. Or you may not be able/want to load test specs by inspecting your path.
Similar to how "package.loaders" works we want to load our test files from a different source, not the filesystem (lfs) based
Unfortunately, we have a hard requirement on LFS for this case since we need to be able to discover test files. Lua does not provide this functionality out of the box so we'd have to depend on -something- and it might as well be LFS.
The solution on this strawman system is to create an in memory traditional filesystem of some sort and write the files there, then run busted against that.
I ran into trouble with this too. The problem I ran into with this is that busted.runner gets its configuration directly from arg, and there doesn't seem to be a way to override that. I solved it by resetting arg to an empty table, which is a lame hack, but got the job done.
Edit: oops; my workaround is woefully inadequate. I can't get busted to run a single test when calling it programmatically.
The busted.runner function accepts an options table, which seems to be the right thing to use if you want to customize it programmatically. However, it still checks arg even if options is provided.
I would suggest that because options implies you are doing your own customization, that it ignore arg if it is present. Getting options from the command-line should be mutually-exclusive with getting them from a function call.
However, if this suggestion is too likely to break things, perhaps there should be a way to explicitly disable checking arg using the options table?
I'd like to include parts of busted in my program to write integration tests. This program embeds a sandboxed version of Lua. I'd like to provide access to describe, it, and assert, and then run the tests. It shouldn't look for _spec files as those will be used by normal unit tests.
How easy would this be to do? Should this been done? What's the best way to do this and reduce the amount of work needed to keep up to date with busted?
I am trying to add tests with busted to https://github.com/rest-nvim/rest.nvim and I fell upon that limitation as well:
https://github.com/lunarmodules/busted/blob/fa948fd8355c598093cac35b106f2d93178118f2/busted/runner.lua#L11 accepts "options" but these are limited: https://github.com/lunarmodules/busted/blob/master/busted/options.lua .
I would like notably to be able to pass the folder where to run.
Skipping local cliArgs, err = cli:parse(arg) if options != empty or merging options with cli args doesn't seem too hard and would allow for programmatic runners.
