feat(e2e/go): E2E tests for the Go SDK
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- go
- Domain
- testing-qa
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.
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
- Dominant language
- Rust
- Stars
- 8.7k
- Forks
- 1.3k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 271
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.
More from NVIDIA/OpenShell
-
area:docs
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
state:triage-needed
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:cli state:validated
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
state:triage-needed
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
area:build spike state:review-ready state:stale
Difficulty 2/5 Half a day Newbie friendliness 68/100
All issues in NVIDIA/OpenShell
Similar issues
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
n0-computer/iroh#4550 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
paritytech/zombienet-sdk#591 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
farion1231/cc-switch#7638 · 1 comment ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100