chore: Adds cli test infra to enabling testing bin invocation

[scalvert]

This PR adds basic bootstrapping of infra that will allow for CLI tests that directly invoke the bin. This can provide a path to end to end tests that will perform a complete migration.

Added:

• execa devDependency for invoking the CLI (I know this project uses child-process, but I've found execa to be really nice for this use case. Happy to discuss whether or not to add this)
• fixturify-project devDependency for building out ad-hoc migration project directories
• A simple example of a cli test using a shepherd util that maps to the bin script, and tests the usage information is correctly printed

The tests are in the standard __tests__ jest directory, mainly because I wasn't sure where to add tests that weren't specifically unit tests (I suppose they could live next to the file itself, as the other tests do).

TODO

• Add a fixturify project subclass to provide utilities for adding a shepherd.yml to the migration directory
• Add the ability to mimic repos to migrate (separate fixturify project directories?)
• Add end to end example of testing a migration, from repo checkout to pr creation
• Exploring using something like https://mswjs.io/ to provide adapter mocking.

[nwalters512]

Just out of curiosity, why is this necessary?

[scalvert]

There was a bug in version 3 of resolve-package-path that I fixed. That fix has not made it into fixturify-project yet, but is largely safe since it's just a change to the files that were published. I'm opening a PR right now to roll that into fixturify-project.

[scalvert]

I've been letting this percolate over the holidays. I think I have a nice setup that will allow us to be able to create ad hoc migrations and target repos, and will also allow us to run full migration tests across those. I also think it'd be nice to provide test infra for migration authors to validate their migrations will run correctly. In that sense, decoupling the utils that allow you to generate fake target repos to run the migrations against would be useful to provide publicly to consumers.

@nwalters512 - what do you think?

[nwalters512]

I also think it'd be nice to provide test infra for migration authors to validate their migrations will run correctly. In that sense, decoupling the utils that allow you to generate fake target repos to run the migrations against would be useful to provide publicly to consumers.

Can you share a little more of what you have in mind? This could be useful, but I'd want to hear more details first.

[scalvert]

@nwalters512 let me work on getting test infra setup that allows us to generate target repos in our CLI tests. Once I've taken a stab at that, we can see if we like it and if we want to extend it past this PR (in a separate PR, of course). Sound good?

At a high level, I'd like to:

• be able to generate a migration dynamically
• be able to generate target repositories locally
• run the migration against those target repositories

We'd need to skip the interactions with the VCS, which we could accomplish by providing test-specific adapters that simple capture the commands we'd run that can be asserted on in tests.

[scalvert]

So I'm going to continue the work on this PR (sorry for the delay!). I'm going to narrow the focus of adding some functionality to simply test dynamically creating a migration and a target repo, and running through those tests.

Subsequent PRs can add public test helper support to exercise testing a migration for migration authors.