Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
116 changes: 116 additions & 0 deletions internal/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
# Development Guide: Testing Local test-server Changes

## Overview
This guide outlines the standard procedure for compiling and testing local modifications to the Go test-server. The test-server is a Go application distributed via language-specific SDK wrappers for ease of adoption.

The recommended workflow for end-to-end validation is to test through the SDK sample. This ensures that any changes to the core Go binary are compatible with the SDK integration layer.

## Step-by-Step e2e Testing Workflow with TypeScript SDK

The process involves compiling your local Go source code, preparing the TypeScript environment, and then linking your new binary to the sample project for testing.

Step 1: Compile the Go Binary

First, compile your local changes into an executable test-server binary.

Navigate to the project's root directory (`test-server`) and build the Go application.

```sh
go build
```

After a successful build, a new executable named `test-server` will be present in the root directory.

Step 2: Build the TypeScript SDK Wrapper

The TypeScript SDK acts as a wrapper around the Go binary. It must be built before we can use it in the TypeScript samples.

Navigate to the TypeScript SDK directory: `test-server/sdks/typescript`.

Install dependencies and build the SDK package.

```sh
npm install
npm run build
```

Step 3: Prepare the Sample Test Project

The sample project consumes the TypeScript SDK. We will set it up to run our tests.

Navigate to the sample project directory: `test-server/sdks/typescript/samples`.

Install its dependencies. This command installs the test-server-sdk we just built in step 2.

```sh
npm install
```

Step 4: Link Your Local test-server Binary
This is the most critical step. You must replace the pre-packaged binary in the sample project's dependencies with the custom binary you built in Step 1.

After the previous steps, the directory structure looks like this. The goal is to replace the test-server binary highlighted below, the graph below is a tree view of your directory structure from `test-server/sdks/typescript/samples`.

```diff
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is nice to add a detailed structure diagram to help understand the structure, my only concern is we may update the structure in the future and may forget to update this structure.

Copy link
Copy Markdown
Collaborator Author

@wanlin31 wanlin31 Aug 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I want to put it there is, it is really hard to describe which binary to replace, I want to demonstrate that it is the one inside the samples folder would make it effective.

I myself accidentally replaced the ones that in the sdks/typscript/bin/, didn't work at all. I think the better way is to have the CI run this test and we can refer to CI's workflow for manual test.

I will create a internal bug for add the CI and update this documentation.

For now, it serve as a starting point for team members to try the local build. :) Hope that is okay.

├── dist
│   └── specs
│   ├── sample.spec.js
│   └── sample.spec.js.map
├── jasmine.json
├── node_modules
│   ├── ... (other packages hidden)
│  ├── test-server-sdk
│   │   ├── bin
│   │   │   ├── CHANGELOG.md
│   │   │   ├── LICENSE
│   │   │   ├── README.md
+│  │   │   └── test-server
│   │   ├── checksums.json
│   │   ├── LICENSE
│   │   ├── package.json
│   │   └── postinstall.js
│   └── ... (other packages hidden)
├── package.json
├── package-lock.json
├── src
│   └── specs
│   └── sample.spec.ts
├── test-data
│   ├── config
│   │   └── test-server-config.yml
│   └── recordings
└── tsconfig.json

```

From the `test-server/sdks/typescript/samples` directory, run the following command to move your freshly compiled binary into place, overwriting the old one.

```sh

# Move the test-server binary from the project root to the samples' node_modules directory.
mv ../../../test-server ./node_modules/test-server-sdk/bin/test-server
```

Step 5: Run the Integration Tests

You are now ready to run the sample project's test suite against your local test-server build.

From the `test-server/sdks/typescript/samples` directory:

To run tests in playback mode:

```sh
#To run tests in replay mode:
npm run test
#To run tests in record mode (and regenerate test recordings):
npm run test:record
```

Any output or errors from the test run will now reflect the behavior of your local test-server changes.

You should also see the actual command run like this:

```
[test-server-sdk] Starting test-server in 'replay' mode. Command: /usr/local/google/home/test-server/sdks/typescript/sample/node_modules/test-server-sdk/bin/test-server replay --config /usr/local/google/home/wanlindu/test-server/sdks/typescript/sample/test-data/config/test-server-config.yml --recording-dir /usr/local/google/home/wanlindu/test-server/sdks/typescript/sample/test-data/recordings
```
You can cross check if you have used the binary you just provided.
5 changes: 5 additions & 0 deletions internal/replay/replay_http_server.go
Original file line number Diff line number Diff line change
Expand Up @@ -178,6 +178,11 @@ func (r *ReplayHTTPServer) writeResponse(w http.ResponseWriter, resp *store.Reco
w.Header().Add(key, value)
}

// When the response body is empty we return directly with the headers.
if len(resp.BodySegments) == 0 {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wdyt to write the headers? and skip write json bytes

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the follow up CL, sorry I missed your comment :)

return nil
}

w.WriteHeader(int(resp.StatusCode))

if !strings.Contains(req.URL, "alt=sse") {
Expand Down
4 changes: 2 additions & 2 deletions sdks/typescript/sample/src/specs/sample.spec.ts
Original file line number Diff line number Diff line change
Expand Up @@ -59,8 +59,8 @@ describe('Sample Test Suite (with test-server)', () => {
});

res.on('end', () => {
expect(data.toLowerCase()).toContain('github');
console.log('[SampleSpec] Received response, content check passed (basic).');
expect(JSON.stringify(res.headers)).toContain('github');
console.log('[SampleSpec] Received response. Because the body of the response can be empty, test headers instead.');
resolve();
});
});
Expand Down
Loading