feat(e2e/go): E2E tests for the Go SDK
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 8.7k
- Forks
- 1.3k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 253
Description
User Story
As a contributor working on OpenShell Go SDK I want mise run e2e:go to run E2E tests against a real
gateway. Regressions in sandbox lifecycle, exec, provider credential injection, and workspace management will be caught before they reach SDK consumers.
Problem Statement
The Go SDK (sdk/go/) is tested only by unit tests and sdk/go/openshell/v1/integration_test.go, which is only a very basic smoke E2E test. New E2E Go SDK test suite should be able to catch issues with:
- protocol schema mismatches between the Go SDK and the actual gateway build
- sandbox lifecycle can be managed by the Go SDK
- provider credentials management using the Go SDK
- workspace management
Impact / Why This Matters
The Go SDK (sdk/go/) is tested mostly by unit tests. These tests mock the transport and never talk to a real openshell-gateway. Which means that currently:
- A gateway change can silently break every Go SDK consumer
- Contributors have no
mise runentry point to test Go SDK changes end-to-end before opening PR
Proposed Design
- Separate module: E2E tests live in
e2e/go/ - No SDK changes:
sdk/go/is untouched
Possible design can be found in draft PR: https://github.com/jiripetrlik/OpenShell/pull/1
Acceptance Criteria
e2e/go/is a separate Go module- All e2e files has
//go:build e2e - Sandbox tests cover CRUD
- Provider tests assert placeholders (not raw secrets)
- Workspace tests cover CRUD
- AGENTS.md documents the
e2e/go/conventions mise run pre-commitpasses; commits are DCO-signed and follow Conventional Commits
Alternatives Considered
- Rely on unit tests - can be faster to test, but many possible bugs can be missed
- Put the e2e tests inside `sdk/go/ - put E2E tests to a separated directory is much more clear
Agent Investigation
No response
Checklist
- I've reviewed existing issues and the architecture docs
- This is a design proposal, not a "please build this" request
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing sdk/go/openshell/v1/integration_test.go and the draft PR linked in the issue, then inspect the proposed e2e/go module conventions. The work is done when build-tagged E2E tests cover sandbox and workspace CRUD, provider placeholder assertions, and the documented mise commands pass alongside mise run pre-commit.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100