WSLC SDK Initial Tests#14232
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request adds initial test coverage for the WSLC SDK (Windows Subsystem for Linux Container SDK), providing both functional tests for implemented APIs and placeholder tests for not-yet-implemented functionality. The tests follow patterns established in the existing WSLATests.cpp and provide comprehensive coverage of session management, image operations, container lifecycle, and process I/O handling.
Changes:
- Added WslcSdkTests.cpp with test coverage for WSLC SDK session, image, container, and process APIs
- Added placeholder tests expecting E_NOTIMPL for APIs not yet implemented
- Updated CMakeLists.txt to include the new test file and link against the wslcsdk library
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| test/windows/WslcSdkTests.cpp | New test file with 30+ test methods covering WSLC SDK functionality including session creation/termination, image pulling, container lifecycle, process I/O handling, and placeholder tests for unimplemented APIs |
| test/windows/CMakeLists.txt | Added WslcSdkTests.cpp to SOURCES, included WslcSDK headers, linked wslcsdk library, and added wslcsdk to dependencies |
test/windows/WslcSdkTests.cpp
Outdated
| { | ||
| if (session) | ||
| { | ||
| WslcSessionTerminate(session); |
There was a problem hiding this comment.
I recommend validating the return value of these (even in the RAII helpers) since we're validating the SDK behavior here
There was a problem hiding this comment.
I'm not seeing a VERIFY_SUCCEEDED_LOG type macro in TAEF. I doubt that we want to terminate the process if these are happening during an exception in the test. We could try/catch it, but would that actually cause the test to fail due to error logging?
In addition, these are attempting to do maximum cleanup for idempotency reasons. Tests can and should call these cleanup functions and verify the output as part of running the main test body.
Do you want it to be a requirement that the runtime always returns a success on repeat calls to these cleanup functions?
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
||
| TEST_METHOD(PullImage) | ||
| { | ||
| WSL2_TEST_ONLY(); |
There was a problem hiding this comment.
We might need to disable this test for now, or add handling for when we hit the API limit given that this is already hitting in our CI
There was a problem hiding this comment.
Does pull always cost us in the rate limit, or only when the image is net new? These tests share the storage with the WSLA tests and should not be pulling any net new images over what it already does.
If the limit is an issue, have we considered moving to hosting our test containers in an artifact feed that we own?
There was a problem hiding this comment.
Does pull always cost us in the rate limit, or only when the image is net new? These tests share the storage with the WSLA tests and should not be pulling any net new images over what it already does.
That's a good question. I'm actually not sure.
If the limit is an issue, have we considered moving to hosting our test containers in an artifact feed that we own?
We have, but for the short term @yao-msft is working on importing the test images via a nuget package. Long term I think a registry that we own would be the right path, but we'll need to authenticate to it, so that's a bigger effort
2 participants
Summary of the Pull Request
Tests for initial WLSC SDK implementation and placeholders for not-yet-implemented APIs.
PR Checklist
Detailed Description of the Pull Request / Additional comments
Adds tests for the implemented portions of the WSLC SDK and placeholders that expect
E_NOTIMPLresults from the unimplemented functions. Based on the WSLA tests as the SDK is a wrapper layer for it.Validation Steps Performed
Ran these tests.