e2e-s3.md

Yes, converting this to a Go test or a Go-based runner is highly recommended. Using shell scripts to "move folders around" to filter tests is brittle and can leave your testdata in a corrupted state if the script crashes.

In Go, the idiomatic way to solve this is using Subtests and Filtering via go test -run.

The "Go Way" Refactor

Instead of a shell script that moves files, create a Go test file (e.g., internal/core/enginetest/e2e_test.go) that dynamically discovers and filters the test cases.

package enginetest

import (
	"os"
	"path/filepath"
	"strings"
	"testing"
)

func TestE2E(t *testing.T) {
	root := "../../../testdata/e2e"
	entries, err := os.ReadDir(root)
	if err != nil {
		t.Fatalf("failed to read e2e directory: %v", err)
	}

	for _, entry := range entries {
		if !entry.IsDir() {
			continue
		}

		name := entry.Name()
		
		// This is the "Intent-Revealing" filter
		t.Run(name, func(t *testing.T) {
			// If we specifically want only S3 cases during a fast run:
			if testing.Short() && !strings.HasPrefix(name, "e2e-s3-") {
				t.Skip("skipping non-S3 case in short mode")
			}

			// Your actual e2e runner logic goes here
			runE2ECase(t, filepath.Join(root, name))
		})
	}
}

func runE2ECase(t *testing.T, path string) {
	// ... logic to invoke 'stave' and check results ...
}

Why this is better than the Shell Script:

1. Selective Execution: You can now run only S3 tests using standard Go flags: go test ./internal/core/enginetest -run E2E/e2e-s3
2. No "Move" Risks: You are no longer moving files to a tmp directory. If the test crashes, your testdata remains intact.
3. Parallelism: You can add t.Parallel() inside the loop to run S3 tests concurrently, making your "S3-only" run significantly faster than the shell script.
4. Error Handling: You get typed error messages and stack traces instead of generic "FAIL" shell exits.

How to trigger this from your CLI

If you want this to be a command in your CLI (e.g., stave test --s3-only), you can use the os/exec package to run the logic, but the "Designing Errors out of Existence" approach says you should just use the Go test runner.

Recommendation: The "Short" Mode Intent

By using if testing.Short(), you reveal a clear intent:

• Standard Run: go test ./... (Runs everything).
• Developer Feedback Loop: go test -short ./... (Runs only the fast S3 cases).

Verdict: Delete the shell script. It’s a "hack" to work around the lack of a proper Go test runner. By moving this into a Go test with subtests, you align with the Go toolchain and make your CI pipeline much more stable.