MR: Pending <!-- NOTE: For context on MR heading, see: https://handbook.gitlab.com/handbook/engineering/devops/dev/create/remote-development/index.html#relationship-of-issues-to-mrs --> ## Description Explore the ideas raised in [this comment](https://gitlab.com/groups/gitlab-org/-/epics/18056#note_2562208349) > @ealcantara Excellent points, and you are thinking outside of the box, as usual. > > This comment especially made me think of new possibilities: > > > Can we test the lifecycle of creating, starting, and running, and terminating a Workspace using API-driven tests? > > Given that a Workspace can be completely created via API, and also should be accessible via SSH, theoretically we could write a completely non-UI, non-Capybara-driven E2E test, which performs all manipulations/assertions via SSH. > > Theoretically, this could also also include direct manipulation/assertion of VS Code itself, via the VS Code server APIs. > > This idea is very appealing to me, because it completely eliminates the slowness/flakiness/maintenance overhead of Capybara-based browser tests, which was part of the pain I was hoping to reduce by moving to Playwright. > > Of course we would still have some Capybara-based tests, but those would be minimal and mostly to exercise the happy-path of the GitLab webapp Workspaces UI behaviors, not the actual in-workspace behavior. ## Acceptance criteria TODO: Fill out (required) - [ ] [Describe what must be achieved to complete this issue.] - [ ] [If applicable, please provide design specifications for this feature/enhancement.] - [ ] [If applicable, please list any technical requirements (performance, security, database, etc.)] ## Implementation plan TODO: Fill out or delete (optional) [Provide a high-level plan for implementation of this issue, including relevant technical and/or design details.] <!-- NOTE: Feel free to expand with more sections and headers as needed --> <!-- DO NOT TOUCH BELOW -->