Move workspace test into e2e format

[mkatychev]

NIT: I really wonder if these should be fixtures. Feels wasteful to add like 10 new folders, but also feels unfortunate to write temp files in the unit tests.

Originally posted by @vados-cosmonic in #231 (comment)

Mimic #[cargo_test] e2es:
https://github.com/rust-lang/cargo/blob/a595d0da21f228b7fdae64d3d5c0e527ea66bb59/tests/testsuite/workspaces.rs#L2867-L2932

[vados-cosmonic]

I'm not sure we need to mimic cargo for everything -- but if we can find a way where unit tests don't do file I/O IMO that would be great

[EDIT] - And one concern is that I don't want to expose too many internal functions/add to the public API just to do this -- if that happens we might as well just add fixture files and only read them.

[mkatychev]

Agreed that not everything should be copied from cargo but I think a pattern where we set up a scenario and possibly run commands in a similar fashion would be quite clean:

#[wkg_test]
fn transitive_path_dep() {
    // dir
    // ├── example-a
    // │   └── wit
    // │       └── pkg.wit
    // ├── example-b
    // │   └── wit
    // │       └── pkg.wit
    // ├── example-c
    // │   └── wit
    // │       └── pkg.wit
    // └── example-d
    let p = project()
        .file(
            "wkg.toml",
            r#"
                [workspace]
                members = [ "example-*/wit" ]
            "#,
        )
        .file("example-a/wit/pkg.wit", "")
        .file("example-b/wit/pkg.wit", "")
        .file("example-c/wit/pkg.wit", "")
        .dir("example-d");
        .build();
    let p = p.build();
    let expected = ["example-a/wit", "example-b/wit", "example-c/wit"];
    let mut actual = p.workspace().root().unwrap().members;
    actual.sort();
    assert_eq!(expected, actual);
}

[vados-cosmonic]

Ah I certainly do like that -- it's pretty clean!

As far as the unit tests go, I wonder if we could add an fs abstraction with something we can swap out during tests to be in-memory only, that would also be a reasonable way to avoid hitting the disk in unit tests (we could also cfg(test) it so it actually doesn't leak out). Of course if we're moving those tests to the e2e area without changing the API then I'm certainly happy with that too. Maybe that's over-engineering though.

Out of curiosity, what is wkg_test?

[mkatychev]

wkg_test would be a hypothetical proc macro that would do at least these things:

• create a temp virtual home directory (that avoids reading the user's - an issue I've been running into)
• create a temp directory for the project/workspace
• handle requirements like detecting if we need an OCI registry: #[wkg_test(container_test)]

[vados-cosmonic]

Ahhhh that seems like a lot, can we do that with some functions or an in-test macro? And as far as having a temp virtual home directory... is that any different from a regular temp directory & supplying config to the run?

I'd like to avoid introducing new macros at that level in general, people generally expect to see tokio::test or test and not have to think too hard, I think.

[mkatychev]

Yes, these are all wishlists. To your point, we can probably do this without proc macros.

And as far as having a temp virtual home directory... is that any different from a regular temp directory & supplying config to the run

I feel it's important to test how the home directory interacts with a workspace/project. There's quite a bit of behaviour that (especially if we were to move to config-rs) is unexpected when merging home and provided configs.

The tests already pick up your ~/.config/wasm-pkg/config.toml which I think we would both agree is undesirable from a testing perspective.