-
Notifications
You must be signed in to change notification settings - Fork 90
tests(compute-static): add basic unit tests #801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
777d322 to
3b16d8b
Compare
amustaque97
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
| #!/bin/bash | ||
|
|
||
| # Start the Python HTTP server in the background, which will act as primary host for requests sent from Rust tests | ||
| python3 scripts/test_http_server.py & |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the "real" way to write integration tests is actually another one, using viceroy-lib, directly, running the WASM binary. It's a little more complex, needs a non-wasm subcrate for the binary, bun I once made it work for a project then you could just use mockito to generate a test case specific mock-server. And it's a "real" integration test.
My proposal for this PR would be:
Keep it simple and just for unit-tests. It's already super helpful to be able to write normal unit-tests, without a real server. This small python server has only limited value for testing the many edge cases you want to test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I consider this implementation with the Python HTTP server hacky. I initially implemented it as I would've preferred to add coverage for the send_request_to_s3 function, as it's the common case handled by this compute function.
I didn't think of using viceroy-lib directly, that seems definitely cleaner. I just saw it's also mentioned in Viceroy's README as the suggested way to run integration tests. Considering the need for a subcrate for this kind of test, I also think it might be worth considering whether this is actually needed, and if so having a separate PR - I'll let the maintainers evaluate whether they'd appreciate this or if it's overkill for now.
6fbdfb0 to
360f2ce
Compare
fix: remame compute-static build target to wasip1 fix: pin toolchain to 1.90 due to https://www.fastlystatus.com/incident/378001 tweak: handle version-downloads URL path with/without trailing slash in the same way without permanent redirects refactor: move request/response log collection to log_line to facilitate testing
…2e tests to test the whole flow in a simple case
tests(compute-static): add specific test for http method filter function ci(compute-static): install cargo-nextest and viceroy via taiki-e/install-action chore(compute-static): revert toolchain back to stable since fastly compute now works again on Rust 1.91.1
8df58f9 to
0c4e8d8
Compare
|
I've reverted the toolchain to stable since the incident with Fastly was resolved, and I've removed the test using the background Python server. Let me know if the existing tests are enough or if there's any other case that I can add |
Closes #401 .
This PR adds a few basic unit tests with Viceroy, a local runner for Fastly compute functions. There are a few functions I couldn't test:
set_ttl: there's no way to retrieve the TTL set on a Request struct, and the function itself is trivial;out of scope for this PR (needs to be tested with an integration test due to wasm)send_request_to_s3: this function sends a HTTP request to the backend, and Viceroy does not allow intercepting them (see related issue). This also prevents implementing a test forhandle_request.While working on this, I noticed the build target was still set to
wasm32-wasi(see here), which was breaking builds due to the target not being found - I've renamed it accordingly.Also, I couldn't build the function either with the latest version of Rust (1.91) due to an ongoing incident with Fastly. I've pinned the version to 1.90 to allow builds, again.The incident was resolved, so I reverted the toolchain to stable.The tests have been integrated in the CI as part of the "Rust projects" job, although this step takes slightly less than 6 minutes due to the installation of Viceroy, mostly. If that's too much time, I can look into caching, or we can split it to only download those tools and execute the tests when files change in the compute-static directory with dorny/paths-filter.