Pulumi TDDの極意：インフラストラクチャを「コードとして」完全に制御する技術
インフラストラクチャのコード化（IaC）は、もはや「手動運用の代替」ではない。それは純粋なソフトウェア開発であり、ゆえにテスト駆動開発（TDD）の原則が最も強烈に威力を発揮する領域である。
Terraformの `plan` と `apply` の泥沼、あるいは「本番環境にデプロイするまでバグに気づかない」という絶望的なフィードバックループに別れを告げよう。Pulumiを用いれば、汎用プログラミング言語の表現力をそのまま活用し、ミリ秒単位のユニットテストから、実クラウドを巻き込んだ統合テストまでを完璧なパイプラインに統合できる。
本稿では、Pulumiの内部アーキテクチャとエンジン・プロバイダー間のRPC通信の特性を理解した上で、極限まで洗練されたTDDパイプラインを構築する実践的知見を授ける。
—
1. なぜIaCにTDDが必要なのか：Pulumiのアーキテクチャから紐解くテスト戦略
Pulumiのエンジンは、TypeScript/Python/Goなどの言語ランタイムと、Goで書かれたリソースプロバイダー（AWS, GCP等）の間で、gRPCを用いた非同期通信を行っている。この「言語の自由度」こそが、Pulumiを単なる設定言語（HCLなど）の枠組みから解放し、高度なテスト自動化の土俵に立たせる最大の理由だ。
インフラストラクチャのテストには、明確な階層がある。
1. Unit Test（ユニットテスト）: クラウドと通信せず、リソースのプロパティや命名規則、セキュリティポリシー（暗号化の有効性など）をメモリ上で数ミリ秒で検証する。
2. Integration Test（インテグレーションテスト）: 一時的なテスト用スタック（Ephemeral Stack）を実際にクラウド上にデプロイし、ライフサイクル全体（Create -> Update -> Destroy）の整合性を検証する。
これらを組み合わせ、「コードを書く前に失敗するテストを書く」。これがIaCにおけるTDDの本質である。
—
2. モックを使った高速なユニットテストの実装（TypeScript & Jest）
クラウドAPIを一切叩かず、リソースの生成ロジックとプロパティを検証するユニットテストを実装する。Pulumiの `pulumi.runtime.setMocks` を用いることで、スタックのデプロイメントを完全にモック化できる。
以下の例では、「すべてのS3バケットにサーバーサイド暗号化が強制され、パブリックアクセスがブロックされていること」を検証するモジュールとテストコードを示す。
対象のインフラストラクチャコード (`index.ts`)
import as pulumi from “@pulumi/core”;
import as aws from “@pulumi/aws”;
interface SecureBucketArgs {
bucketName: string;
environment: string;
}
export class SecureBucket extends pulumi.ComponentResource {
public readonly bucket: aws.s3.Bucket;
constructor(name: string, args: SecureBucketArgs, opts?: pulumi.ComponentResourceOptions) {
super(“custom:module:SecureBucket”, name, {}, opts);
// セキュリティ要件を強制したS3バケットの定義
this.bucket = new aws.s3.Bucket(`${name}-bucket`, {
bucket: args.bucketName,
tags: {
Environment: args.environment,
ManagedBy: “Pulumi”,
},
}, { parent: this });
// パブリックアクセスブロック
new aws.s3.BucketPublicAccessBlock(`${name}-pab`, {
bucket: this.bucket.id,
blockPublicAcls: true,
blockPublicPolicy: true,
ignorePublicAcls: true,
restrictPublicBuckets: true,
}, { parent: this });
// 暗号化の強制
new aws.s3.BucketServerSideEncryptionConfigurationV2(`${name}-sse`, {
bucket: this.bucket.id,
rules: [{
applyServerSideEncryptionByDefault: {
sseAlgorithm: “AES256”,
},
}],
}, { parent: this });
}
}
ユニットテストコード (`index.test.ts`)
import as pulumi from “@pulumi/core”;
// Pulumiのランタイムをモック化する
pulumi.runtime.setMocks({
newResource: (args: pulumi.runtime.MockResourceArgs): { id: string, state: Record
return {
id: `${args.name}-id`,
state: {
…args.inputs,
// クラウド側で付与される暗黙的なプロパティを模倣
arn: `arn:aws:s3:::${args.inputs.bucket || “default”}`,
},
};
},
call: (args: pulumi.runtime.MockCallArgs) => {
return args.inputs;
},
});
import { SecureBucket } from “./index”;
describe(“SecureBucket Component Unit Tests”, () => {
let comp: SecureBucket;
beforeAll(() => {
// テスト対象のコンポーネントをインスタンス化
comp = new SecureBucket(“test-secure”, {
bucketName: “my-ultra-secure-bucket-12345”,
environment: “production”,
});
});
test(“S3 Bucket is created with correct tags”, (done) => {
// Outputプロパティを非同期で解決して検証
pulumi.all([comp.bucket.tags]).apply(([tags]) => {
try {
expect(tags).toMatchObject({
Environment: “production”,
ManagedBy: “Pulumi”,
});
done();
} catch (error) {
done(error);
}
});
});
test(“Public access block resource must be declared”, () => {
// リソースツリーが正しく構築されているかを構造レベルで検証
// （実際にはリソースの種別や依存関係をモックステートから走査）
expect(comp).toBeDefined();
});
});
このテストは、ネットワークI/Oを一切発生させず、数ミリ秒で完了する。CIの初手でこれを走らせることで、構文エラーやポリシー違反を瞬時に弾く。
—
3. 実クラウドで執行するインテグレーションテスト（Ephemeral Stack戦略）
ユニットテストが「コードの意図」を検証するのに対し、インテグレーションテストは「クラウドプロバイダーとの実際の統合」を検証する。ここで重要になるのが、完全なアイソレーション（独立性）を担保した一時的スタック（Ephemeral Stack）の自動ライフサイクル管理だ。
PulumiのAutomation APIを使用すると、コード内からスタックの初期化、プレビュー、アップグレード、破棄（Destroy）をプログラムから完全に制御できる。
以下は、TypeScriptを用いたインテグレーションテストの極みである。テスト実行時に動的に一意なスタックを作成し、リソースをデプロイ、HTTPリクエスト等で疎通確認を行った後、確実に `destroy` を走らせる堅牢なテストハーネスの実装だ。
インテグレーションテストの実装 (`integration.test.ts`)
import as pulumi from “@pulumi/pulumi”;
import as auto from “@pulumi/pulumi/automation”;
import as http from “http”;
describe(“Infrastructure Integration Test”, () => {
const stackName = `integration-test-${Math.random().toString(36).substring(2, 7)}`;
let stk: auto.Stack;
beforeAll(async () => {
// 1. ワークスペースの初期化とインラインプログラムの定義
const workDir = “./test-project”; // テスト対象のPulumiプロジェクトディレクトリ
stk = await auto.LocalWorkspace.createOrSelectStack({
stackName: stackName,
workDir: workDir,
});
// 2. 設定の流し込み（AWSリージョンなど）
await stk.setConfig(“aws:region”, { value: “us-east-1” });
// 3. 実際のデプロイメントの実行（pulumi up相当）
console.log(`Starting deployment for stack: ${stackName}…`);
const upRes = await stk.up({ onOutput: console.log });
console.log(`Deployment complete. Outputs: ${JSON.stringify(upRes.outputs)}`);
}, 300000); // クラウド構築を考慮しタイムアウトは5分に設定
afterAll(async () => {
// 4. クリーンアップの強制（pulumi destroy相当）。テストが失敗しても必ず実行される
if (stk) {
console.log(`Destroying stack: ${stackName} to prevent resource leakage…`);
await stk.destroy({ onOutput: console.log });
await stk.workspace.removeStack(stackName);
console.log(“Cleanup completed.”);
}
}, 300000);
test(“Cloud resources are provisioned and accessible”, async () => {
const outputs = await stk.outputs();
// 例: デプロイされたAPI GatewayのURLなどを取得して検証
const endpoint = outputs.apiUrl.value;
expect(endpoint).toBeDefined();
expect(endpoint).toMatch(/^https:\/\/.+/);
// 実際のHTTPリクエストによる疎通テスト
const isHealthy = await new Promise
http.get(endpoint, (res) => {
resolve(res.statusCode === 200);
}).on(“error”, () => {
resolve(false);
});
});
expect(isHealthy).toBe(true);
});
});
この手法の優れている点は、「テストの失敗がリソースの放置につながらない」という点にある。`afterAll` フックが確実にクリーンアップを実行するため、クラウドのコスト爆発やセキュリティリスクを完全に排除できる。
—
4. 品質を極限まで高めるCIパイプラインの設計（GitHub Actions）
ユニットテストとインテグレーションテストを組み合わせた、妥協なきCI/CDパイプラインを構築する。
ここでは、単なる逐次実行ではなく、マージ前は高速なユニットテスト、メインブランチへのマージ時（または夜間）にインテグレーションテストを走らせる、実戦的なパイプライン設計を示す。
`.github/workflows/pulumi-tdd.yml`
name: Pulumi TDD Pipeline
on:
pull_request:
branches: [ main ]
push:
branches: [ main ]
permissions:
id-token: WIF # OIDC認証を使用（AWS長期クレデンシャルの排除）
contents: read
jobs:
unit-test:
name: Fast Unit Testing
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
- name: Install Dependencies
run: npm ci
- name: Run Unit Tests
run: npm run test:unit
integration-test:
name: Cloud Integration Test
needs: unit-test
if: github.ref == ‘refs/heads/main’ # 本番相当の統合テストはメインブランチのみ、あるいはPR毎に条件分岐
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
- name: Install Dependencies
run: npm ci
- name: Configure AWS Credentials via OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsPulumiRole
aws-region: us-east-1
- name: Login to Pulumi
uses: pulumi/actions@v5
with:
command: login
env:
PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
- name: Run Integration Tests
run: npm run test:integration
env:
PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
—
5. エキスパートの知見：メモリ消費、並行性、およびコスト最適化のハック
大規模なインフラストラクチャコードベースにおいて、テスト駆動開発をスケールさせるための実践的かつ高度な最適化ハックを共有する。
1. ユニットテストにおけるモックの並列実行競合の回避
Jestはデフォルトでテストファイルを並列実行するが、`pulumi.runtime.setMocks` はグローバルなランタイム状態を書き換えるため、複数のテストファイルが同時にモックを初期化すると、状態の汚染（Pollution）による予期せぬテスト失敗を引き起こす。
- 解決策: ユニットテストは単一のファイルに集約するか、Jestの `–runInBand` オプションを使用して直列実行を強制せよ。
2. インテグレーションテストの並列化とリソース衝突（Name Collision）
複数のPRが同時にインテグレーションテストを走らせた場合、S3バケット名やIAMロール名がグローバル名前空間で衝突する。
- 解決策: スタック名やリソースのサフィックスには必ず `crypto.randomBytes(4).toString(‘hex’)` または GitHub Actionsの `github.run_id` と `github.run_attempt` を組み込み、完全に名前空間を分離（Namespace Isolation）すること。
3. ステートロックとメモリ管理
Automation APIを用いたインテグレーションテストは、Node.jsプロセスのメモリ消費量が急増しやすい。特に多数のリソースを動的に生成・破棄する際、ガベージコレクションが追いつかないことがある。
- 解決策: CIランナーのメモリ制限を監視し、必要に応じて `NODE_OPTIONS=”–max-old-space-size=4096″` を指定してV8エンジンのヒープサイズを拡張せよ。
—
結び
インフラストラクチャの構築を「お祈りデプロイ」の時代から、「数学的・論理的検証が完了したソフトウェアエンジニアリング」へと昇華させる鍵は、Pulumiを活用したTDDの徹底にある。
テストコードという名の「防壁」を最初に築き上げよ。その時、あなたのデプロイパイプラインは、恐怖の対象から、絶対的な信頼を置ける「最強の自動化エンジン」へと生まれ変わるはずだ。