test: add test cases for serve

[FrankYang0529]

resolves #1 #2

[lann]

Stray println

[FrankYang0529]

Removed it. Thank you.

[FrankYang0529]

Hi reviewers, this is my first time writing test cases for a wasm target. Thanks for your review and guidance. I have two questions.

1. Not sure whether it's right to use wasm-pack test --node. Is there a convenient way to use the cargo test for testing wasm?
2. I would like to write a positive test case for the serve function, but I can't get a 200 response even though I use the complete path.

[lann]

Thanks for the PR!

It doesn't look like these tests really depend on being run in a Wasm environment; I tested locally by replacing #[wasm_bindgen_test] with #[test] and running cargo test --target=x86_64-unknown-linux-gnu which worked fine. We should see if there is a nice way to set up .cargo/config.toml so that tests don't need to cross-compile.

[lann]

I don't see anything obvious in the cargo docs to simplify it, but for the purposes of this PR I think we can use this slightly awkward command in the Makefile: cargo test --target=$$(rustc -vV | sed -n 's|host: ||p')

[FrankYang0529]

I don't see anything obvious in the cargo docs to simplify it, but for the purposes of this PR I think we can use this slightly awkward command in the Makefile: cargo test --target=$$(rustc -vV | sed -n 's|host: ||p')

Yeah, this is a good idea. I just saw that cargo merged multiple targets a few days ago. Probably, we can also try it?

rust-lang/cargo#8176

[FrankYang0529]

Hi @lann, I update test cases and add CI. Please help me review when you have time. Thank you.

[lann]

This can be simplified a lot for this repo - much of what we want to test for spin doesn't apply here. If you'd like to drop this from your PR I can add something simple in a followup.

[FrankYang0529]

Removed it. Thank you.

[itowlson]

Forgive me if I'm misreading, but it looks like you dropped this line and kept the rest of the file. If we keep the file (which is what I think @lann was questioning), then we should keep this line. The reason is that this declaration avoids squigglies when editing the workflow in VS Code if you have the YAML extension installed. The YAML language server seems to recognise certain filenames and infer a schema, and for build.yaml it infers something other than GH workflow and complains about the 'wrong' entries.

Again, if I've misunderstood then please ignore me!

[lann]

I realized my comment was unclear so I refactored in #17. I just opened #18 to add the comment back

[lann]

Thanks for the PR!