# How to Test the GitHub-Asana Request Review Action Locally Before Production

> Test the GitHub-Asana Request Review Action locally before production by running Go unit tests or executing the binary with sample payloads. Avoid live API calls.

- Repository: [Keita Kitamura/github-asana-request-review-action](https://github.com/keitap/github-asana-request-review-action)
- Tags: how-to-guide
- Published: 2026-03-05

---

**You can test the GitHub-Asana Request Review Action locally by running its Go unit tests with `make test` or executing the binary directly against sample webhook payloads in the `testdata/` directory, eliminating the need for live GitHub or Asana API calls.**

The `keitap/github-asana-request-review-action` is a Go-based GitHub Action that automates Asana task creation when pull requests request reviews. Because the core logic resides in standard Go packages rather than GitHub-specific wrappers, you can validate every code path on your local workstation before deploying to production.

## Architecture Overview

The action is structured as a conventional Go project where business logic is decoupled from the GitHub Actions runner. This design makes local testing straightforward.

| Component | Purpose | Key File |
|-----------|---------|----------|
| **Entry point** | Reads GitHub event payloads, initializes clients, and invokes the handler | [`cmd/main.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/cmd/main.go) |
| **Configuration loader** | Unmarshals YAML settings into the `Config` struct | [`config.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/config.go) |
| **Event handler** | Parses webhooks and orchestrates Asana subtask creation | [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go) |
| **Unit tests** | Exercises handler flows with synthetic payloads | [`handler_test.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler_test.go) |
| **Build automation** | Defines the `test` target for the suite | `Makefile` |

The [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go) file contains the primary orchestration logic, distinguishing between `PullRequestEvent` and `PullRequestReviewEvent` via `github.ParseWebHook`, while [`cmd/main.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/cmd/main.go) serves as the thin CLI wrapper used by the GitHub Actions runtime.

## Local Testing Methods

### Running the Unit Test Suite

The fastest way to verify logic is through the existing test suite, which mocks webhook payloads without making real API calls.

1. **Clone the repository and install Go** (version 1.22 or later recommended):

```bash
git clone https://github.com/keitap/github-asana-request-review-action.git
cd github-asana-request-review-action

```

2. **Set placeholder environment variables**. The tests require token values to instantiate clients but do not transmit them over the network:

```bash
export ASANA_TOKEN=dummy-token
export GITHUB_TOKEN=dummy-token

```

3. **Execute the full test suite** using the Makefile target:

```bash
make test

```

4. **Run a specific test case** to isolate particular handlers:

```bash
go test -run TestHandler_handlePullRequestEvent ./...

```

### Testing as a Standalone Binary

You can invoke the exact binary used in production by feeding it synthetic GitHub webhook payloads stored in the `testdata/` directory.

Execute the binary with a pull request review requested event:

```bash
go run ./cmd \
  INPUT_CONFIG_PATH=.github/github-asana-request-review.yml \
  GITHUB_EVENT_NAME=pull_request \
  GITHUB_EVENT_PATH=./testdata/pull_request_review_requested.json

```

Simulate a review submission event by switching the payload:

```bash
go run ./cmd \
  INPUT_CONFIG_PATH=.github/github-asana-request-review.yml \
  GITHUB_EVENT_NAME=pull_request_review \
  GITHUB_EVENT_PATH=./testdata/pull_request_review-submitted-approved.json

```

The binary logs the same execution trace you would see in GitHub Actions, including parsed Asana task URLs and reviewer assignments, without modifying live data.

### Building and Running the Compiled Binary

For repeated testing, compile the binary once and reuse it:

```bash
go build -o asana-action ./cmd

./asana-action \
  INPUT_CONFIG_PATH=.github/github-asana-request-review.yml \
  GITHUB_EVENT_NAME=pull_request \
  GITHUB_EVENT_PATH=./my-custom-payload.json

```

### Emulating the GitHub Actions Runner with Act

To replicate the CI environment including container context, install [act](https://github.com/nektos/act) and run the local workflow:

```bash
act -e ./testdata/pull_request_review-submitted-approved.json \
    -s GITHUB_TOKEN=dummy-token \
    -s ASANA_TOKEN=dummy-token \
    -j asana-integration

```

This executes the job definition from [`.github/workflows/test.yml`](https://github.com/keitap/github-asana-request-review-action/blob/main/.github/workflows/test.yml) on your machine, providing the closest possible parity to production execution.

## Why Local Testing Works

The action supports local validation because of three architectural decisions in the `keitap/github-asana-request-review-action` source code:

- **Pure Go implementation**: All network operations use standard `go-github` and `asana-go` client constructors. When supplied with dummy tokens, these clients initialize but the test suite terminates before transmitting HTTP requests, verifying control flow up to the subtask creation point.

- **Self-contained configuration**: The `LoadConfig` function in [`config.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/config.go) provides sensible defaults (due date of 1 day, empty holiday map), allowing the handler to execute even with minimal YAML configuration.

- **Deterministic date logic**: The `NextBusinessDay` function in [`date.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/date.go) operates on `time.Now()`, enabling ad-hoc testing without date injection, while remaining testable via unit tests when fixed times are required.

## Common Pitfalls and Solutions

| Symptom | Cause | Resolution |
|---------|-------|------------|
| `cannot load config file` error | `INPUT_CONFIG_PATH` points to a non-existent file | Verify the path matches an existing file or use the default [`.github/github-asana-request-review.yml`](https://github.com/keitap/github-asana-request-review-action/blob/main/.github/github-asana-request-review.yml) location |
| Asana API authentication errors | Empty token strings triggering real API attempts | Ensure `ASANA_TOKEN` contains a non-empty dummy value like `dummy-token` for unit tests, or use a real Personal Access Token for integration testing |
| `log: unknown event` message | Invalid `GITHUB_EVENT_NAME` value | Restrict values to `pull_request` or `pull_request_review` as handled in [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go) |

## Summary

- **Unit tests** in [`handler_test.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler_test.go) validate logic without network calls using `make test`
- **Standalone execution** via `go run ./cmd` accepts `GITHUB_EVENT_PATH` pointing to `testdata/` JSON files
- **Environment variables** `ASANA_TOKEN` and `GITHUB_TOKEN` require only placeholder values for local testing
- **Act** provides full GitHub Actions runner emulation using the repository's [`.github/workflows/test.yml`](https://github.com/keitap/github-asana-request-review-action/blob/main/.github/workflows/test.yml)
- **Configuration loading** from [`config.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/config.go) works out-of-the-box with default settings

## Frequently Asked Questions

### Do I need real Asana or GitHub tokens to test locally?

No. For unit testing and standalone binary execution, set `ASANA_TOKEN` and `GITHUB_TOKEN` to any non-empty string like `dummy-token`. The code initializes client objects but the test suite and basic control-flow validation do not transmit HTTP requests. Only integration testing against live APIs requires real Personal Access Tokens.

### How do I test a specific webhook event type like review submission?

Use the `GITHUB_EVENT_NAME` environment variable to switch contexts. Set it to `pull_request_review` and point `GITHUB_EVENT_PATH` to [`./testdata/pull_request_review-submitted-approved.json`](https://github.com/keitap/github-asana-request-review-action/blob/main/./testdata/pull_request_review-submitted-approved.json) (or create a custom JSON file matching GitHub's webhook schema). The [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go) logic will route to `handlePullRequestReviewEvent` accordingly.

### Can I debug configuration loading issues without pushing to GitHub?

Yes. Run the binary locally with `INPUT_CONFIG_PATH` set to your YAML file path. The `LoadConfig` function in [`config.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/config.go) will attempt to parse the file and report errors directly to stderr, allowing you to fix formatting issues before deployment.

### Is there a way to test the exact Docker environment used in production?

Install the `act` CLI tool and run `act -j asana-integration` with the appropriate event file and secret flags. This executes the action inside a Docker container matching the GitHub Actions runner image, using the workflow definition in [`.github/workflows/test.yml`](https://github.com/keitap/github-asana-request-review-action/blob/main/.github/workflows/test.yml) and providing the most accurate pre-production validation.