Add a helper for testing with various plugin configurations

[Julian]

It'd be nice to have a way with plenary's busted support to specify dependencies that test cases have on active plugins.

E.g., imagine a spec file for a function foo which does different things if the user has installed a dependency bar or another dependency baz -- then it'd be nice to have syntax or arguments or etc. which properly manage runtimepath and clearing enough state (or running in enough isolation) such that tests which want to run with bar loaded get that, and tests which want to run with baz loaded get that.

I don't 100% know what a solution to this looks like (though I suppose I'll know that in a few hours after implementing one in a bespoke way for my plugin), but it seems possibly like a thing that'd be more widely useful.

#54 may be related here in a distant way.

[matu3ba]

"spec file for a function" - a spec is just formalized code, which can be represented as code (ie a logic is also code).

As I understand it you want conditionally run integration tests for dependencies, but you are not specific what this interface should generalize over. Or what am I missing?

[Julian]

"spec file for a function" - a spec is just formalized code, which can be represented as code (ie a logic is also code).

That's a different definition of the word "spec". Here it means literally "the file format expected by busted", or plenary which provides a similar API.

As I understand it you want conditionally run integration tests for dependencies, but you are not specific what this interface should generalize over. Or what am I missing?

Sure, as I say when filing this I didn't design a solution, the point was first simply to say "this seems hard and that it shouldn't be".

But such an interface undoubtedly indeed would say which integration tests should run under which sub-vimrc (including runtimepath configuration), perhaps. Putting that within each spec file though is likely too late though, since the test runner likely would want to know that info before farming out the file. So, again brainstorming, a decent place to put that info may instead be in a top-level config file for the test runner, and would map test files to alternate configs.