Day 026 — モック・DI設計（インターフェース経由の依存注入）

📚 背景知識（読んでから問題へ）

Day 023-025ではtesting.T/testing.Bを使ったテスト技法（テーブル駆動テスト・サブテスト・ベンチマーク）を学びました。しかしテストを書こうとすると、すぐに壁にぶつかります。「外部SMTPサーバーにメールを送る処理」「DBに書き込む処理」「外部APIを呼ぶ処理」をテストするたびに、本物のSMTPサーバーやDBが必要になってしまう、という問題です。

この壁を壊すのがDI（Dependency Injection、依存性注入）です。Goには他言語のような専用のDIフレームワーク（JavaのSpring、C#のASP.NET Core組み込みDIコンテナ等）は標準に存在しません。その代わり、Goはインターフェース＋コンストラクタ関数という言語仕様だけでDIを実現します。

考え方はシンプルです。

1. 「外部に依存する処理」をインターフェースとして抽象化する
2. 業務ロジックを持つ構造体は、具体的な実装（SMTPクライアント等）ではなくインターフェース型のフィールドを持つ
3. 実際に使う実装（本物のSMTPクライアント）は、構造体の外（main関数やコンストラクタの呼び出し側）で組み立てて渡す

📋 コピーtype EmailSender interface {
	Send(to, subject, body string) error
}

type OrderService struct {
	sender EmailSender // 具体的な実装ではなく、インターフェース型で持つ
}

func NewOrderService(sender EmailSender) *OrderService {
	return &OrderService{sender: sender}
}

こうしておくと、本番ではSMTPEmailSender（本物のSMTP通信をする実装）を渡し、テストではMockEmailSender（メモリ上に記録するだけの偽実装）を渡すことができます。OrderService自身は「EmailSenderインターフェースを満たす何か」としか認識しないため、どちらを渡されても同じコードで動きます。

Day 020で学んだ「Accept interfaces, return structs」の原則が、まさにここで実務的な価値を発揮します。関数・構造体は受け取る依存をインターフェースで表現し、自分自身は具体的な構造体として返すという非対称な設計が、テスト容易性の土台になっているのです。

Goのモックには大きく2つの作り方があります。

• 手書きモック: インターフェースを満たす小さな構造体を自分で書く。今日はこちらを扱います
• モック生成ツール: gomockやmockery等のツールがインターフェース定義から自動でモックコードを生成する（Phase 3以降、実務規模のコードベースで使う機会が増える）

小規模なインターフェース（メソッド1〜2個）であれば、手書きモックの方がツール導入のコストより軽く、Goコミュニティでも広く推奨されています。「小さいインターフェースを設計すれば、モックも小さく書ける」という点は、Day 020のインターフェース設計原則と直結しています。

📝 問題

ECサイトの注文確定処理を行うOrderServiceを、DIを使ってテスト可能な設計にリファクタリングしてください。

Part A: インターフェース抽出とコンストラクタ注入

以下の密結合な実装があります。

📋 コピーpackage main

import (
	"fmt"
	"net/smtp"
)

type Order struct {
	ID            string
	CustomerEmail string
	TotalYen      int
}

// 密結合な実装：OrderServiceが具体的なSMTP通信を直接知っている
type OrderService struct {
	smtpHost string
	smtpPort int
}

func (s *OrderService) ConfirmOrder(order Order) error {
	if order.TotalYen <= 0 {
		return fmt.Errorf("invalid order total: %d", order.TotalYen)
	}
	body := fmt.Sprintf("ご注文 #%s（合計%d円）を承りました。", order.ID, order.TotalYen)
	addr := fmt.Sprintf("%s:%d", s.smtpHost, s.smtpPort)
	msg := []byte("Subject: ご注文確認\r\n\r\n" + body)
	// smtp.SendMail は本物のネットワーク通信を行うため、単体テストで直接呼べない
	err := smtp.SendMail(addr, nil, "shop@example.com", []string{order.CustomerEmail}, msg)
	if err != nil {
		return fmt.Errorf("send confirmation email: %w", err)
	}
	return nil
}

次の設計変更を行ってください。

1. Send(to, subject, body string) errorという1メソッドのEmailSenderインターフェースを定義する
2. OrderServiceがEmailSenderインターフェース型のフィールドを持つように変更し、NewOrderService(sender EmailSender) *OrderServiceというコンストラクタ関数を用意する（smtpHost/smtpPortのような具体的な接続情報は、本物の実装側の責務に移す）
3. 本物の実装としてSMTPEmailSender構造体を用意し、EmailSenderを満たすようにする（中でsmtp.SendMail相当の処理を呼ぶ想定でよいが、テストでは呼ばれない設計にする）
4. ConfirmOrderメソッドは、注文合計が0円以下ならメールを送らずエラーを返す仕様を維持する

Part B: 手書きモックによるテーブル駆動テスト

EmailSenderを満たすMockEmailSenderを手書きし、次の3ケースを検証するテーブル駆動テストを書いてください。

1. 正常な注文（TotalYen > 0）→ メールが1件送信され、宛先・本文に注文情報が正しく含まれる
2. 不正な注文（TotalYen <= 0）→ メールは送信されず、エラーが返る
3. MockEmailSenderが意図的にエラーを返す設定のとき → ConfirmOrderはエラーを返し、そのエラーに元のエラー（errors.Is等で検証可能な形）が含まれる

MockEmailSenderは送信されたメール（宛先・件名・本文）を[]SentEmailのようなスライスに記録し、テストから検証できるようにしてください。

Part C: 設計判断の言語化

Part Aの元コード（密結合版）をgo testで直接テストしようとすると何が起きるか、また今回のDI導入によってテストがどう変わったかを、次の観点で説明してください。

1. 密結合版のままテストを書いた場合に発生する具体的な問題（実行結果・副作用の観点で）
2. OrderServiceが「本物のSMTP実装の詳細（ホスト名・ポート番号）」を知らなくなったことによる、テスト以外のメリット（将来SMTPをSendGridのようなAPI経由の送信に差し替える場面を想定して）

go run . / go test ./...でそのまま動作する完全なコードとして提示すること。

🔍 ヒント（段階的開示）

📋 コピーtype EmailSender interface {
	Send(to, subject, body string) error
}

type OrderService struct {
	sender EmailSender
}

func NewOrderService(sender EmailSender) *OrderService {
	return &OrderService{sender: sender}
}

func (s *OrderService) ConfirmOrder(order Order) error {
	if order.TotalYen <= 0 {
		return fmt.Errorf("invalid order total: %d", order.TotalYen)
	}
	body := fmt.Sprintf("ご注文 #%s（合計%d円）を承りました。", order.ID, order.TotalYen)
	if err := s.sender.Send(order.CustomerEmail, "ご注文確認", body); err != nil {
		return fmt.Errorf("send confirmation email: %w", err)
	}
	return nil
}

// テストではこう組み立てる
mock := &MockEmailSender{}
svc := NewOrderService(mock)
err := svc.ConfirmOrder(Order{ID: "A1", CustomerEmail: "a@example.com", TotalYen: 1000})
// mock.Sent を検証する

✅ 模範解答

ファイル: main.go

📋 コピーpackage main

import (
	"fmt"
)

// Order は注文情報を表す。
type Order struct {
	ID            string
	CustomerEmail string
	TotalYen      int
}

// EmailSender は「メールを送る」という意図だけを表現するインターフェース。
// OrderService はこのインターフェースにしか依存しない。
type EmailSender interface {
	Send(to, subject, body string) error
}

// SMTPEmailSender は EmailSender の本番実装。
// SMTP接続の詳細（ホスト名・ポート番号）はこの構造体だけが知っている。
type SMTPEmailSender struct {
	Host string
	Port int
	From string
}

// Send は本来 net/smtp.SendMail 等で実際のSMTP通信を行う。
// （本ファイルではネットワークI/Oの実体は割愛し、シグネチャと責務の分離を示す）
func (s *SMTPEmailSender) Send(to, subject, body string) error {
	addr := fmt.Sprintf("%s:%d", s.Host, s.Port)
	// 実際の送信処理はここに書く想定（例: smtp.SendMail(addr, nil, s.From, []string{to}, msg)）。
	_ = addr
	fmt.Printf("[SMTP %s] to=%s subject=%s\n", addr, to, subject)
	return nil
}

// OrderService は EmailSender インターフェース型のフィールドだけを持ち、
// 具体的な送信手段（SMTP/SendGrid API等）を知らない。
type OrderService struct {
	sender EmailSender
}

// NewOrderService は依存（EmailSender）を外部から受け取るコンストラクタ。
// フィールドを直接初期化させず、必須の依存を渡し忘れさせない役割を持つ。
func NewOrderService(sender EmailSender) *OrderService {
	return &OrderService{sender: sender}
}

// ConfirmOrder は注文を確定し、確認メールを送る。
func (s *OrderService) ConfirmOrder(order Order) error {
	if order.TotalYen <= 0 {
		return fmt.Errorf("invalid order total: %d", order.TotalYen)
	}
	body := fmt.Sprintf("ご注文 #%s（合計%d円）を承りました。", order.ID, order.TotalYen)
	if err := s.sender.Send(order.CustomerEmail, "ご注文確認", body); err != nil {
		return fmt.Errorf("send confirmation email: %w", err)
	}
	return nil
}

func main() {
	sender := &SMTPEmailSender{Host: "smtp.example.com", Port: 587, From: "shop@example.com"}
	svc := NewOrderService(sender)

	order := Order{ID: "A1001", CustomerEmail: "customer@example.com", TotalYen: 3500}
	if err := svc.ConfirmOrder(order); err != nil {
		fmt.Println("注文確定エラー:", err)
		return
	}
	fmt.Println("注文確定完了:", order.ID)
}

ファイル: main_test.go

📋 コピーpackage main

import (
	"errors"
	"testing"
)

// SentEmail はモックが記録する送信済みメールの内容。
type SentEmail struct {
	To, Subject, Body string
}

// MockEmailSender は EmailSender を満たす手書きモック。
// 本物のネットワーク通信を一切行わず、呼び出しをメモリ上に記録するだけ。
type MockEmailSender struct {
	Sent []SentEmail
	Err  error
}

func (m *MockEmailSender) Send(to, subject, body string) error {
	if m.Err != nil {
		return m.Err
	}
	m.Sent = append(m.Sent, SentEmail{To: to, Subject: subject, Body: body})
	return nil
}

func TestOrderService_ConfirmOrder(t *testing.T) {
	tests := []struct {
		name        string
		order       Order
		senderErr   error
		wantErr     bool
		wantSentLen int
	}{
		{
			name:        "正常な注文はメールが1件送信される",
			order:       Order{ID: "A1", CustomerEmail: "a@example.com", TotalYen: 1000},
			wantErr:     false,
			wantSentLen: 1,
		},
		{
			name:        "合計0円以下はメールを送らずエラーを返す",
			order:       Order{ID: "A2", CustomerEmail: "b@example.com", TotalYen: 0},
			wantErr:     true,
			wantSentLen: 0,
		},
		{
			name:        "送信エラー時はConfirmOrderもエラーを返す",
			order:       Order{ID: "A3", CustomerEmail: "c@example.com", TotalYen: 500},
			senderErr:   errors.New("smtp connection refused"),
			wantErr:     true,
			wantSentLen: 0,
		},
	}

	for _, tt := range tests {
		tt := tt
		t.Run(tt.name, func(t *testing.T) {
			mock := &MockEmailSender{Err: tt.senderErr}
			svc := NewOrderService(mock)

			err := svc.ConfirmOrder(tt.order)

			if (err != nil) != tt.wantErr {
				t.Fatalf("ConfirmOrder() error = %v, wantErr = %v", err, tt.wantErr)
			}
			if len(mock.Sent) != tt.wantSentLen {
				t.Fatalf("sent emails = %d, want %d", len(mock.Sent), tt.wantSentLen)
			}
			if tt.senderErr != nil {
				if !errors.Is(err, tt.senderErr) {
					t.Fatalf("error chain does not contain sender error: got %v, want wrapping %v", err, tt.senderErr)
				}
			}
			if !tt.wantErr && len(mock.Sent) == 1 {
				got := mock.Sent[0]
				if got.To != tt.order.CustomerEmail {
					t.Errorf("sent To = %q, want %q", got.To, tt.order.CustomerEmail)
				}
				if got.Subject != "ご注文確認" {
					t.Errorf("sent Subject = %q, want %q", got.Subject, "ご注文確認")
				}
			}
		})
	}
}

$ go run .
[SMTP smtp.example.com:587] to=customer@example.com subject=ご注文確認
注文確定完了: A1001

$ go test -v ./...
=== RUN   TestOrderService_ConfirmOrder
=== RUN   TestOrderService_ConfirmOrder/正常な注文はメールが1件送信される
=== RUN   TestOrderService_ConfirmOrder/合計0円以下はメールを送らずエラーを返す
=== RUN   TestOrderService_ConfirmOrder/送信エラー時はConfirmOrderもエラーを返す
--- PASS: TestOrderService_ConfirmOrder (0.00s)
    --- PASS: TestOrderService_ConfirmOrder/正常な注文はメールが1件送信される (0.00s)
    --- PASS: TestOrderService_ConfirmOrder/合計0円以下はメールを送らずエラーを返す (0.00s)
    --- PASS: TestOrderService_ConfirmOrder/送信エラー時はConfirmOrderもエラーを返す (0.00s)
PASS
ok  	example.com/day026	0.003s

go.mod・main.go・main_test.goを1モジュール（module example.com/day026）として配置し、go run . / go test -v ./...で検証済みです。テストは一切のネットワーク通信を行わずミリ秒単位で完走します。

🪜 Step-by-Step 解説

📋 コピーtype EmailSender interface {
	Send(to, subject, body string) error
}

📋 コピーtype SMTPEmailSender struct {
	Host string
	Port int
	From string
}
func (s *SMTPEmailSender) Send(to, subject, body string) error { /* 本物の通信 */ }

📋 コピーfunc NewOrderService(sender EmailSender) *OrderService {
	return &OrderService{sender: sender}
}

📋 コピーmock := &MockEmailSender{}
svc := NewOrderService(mock)

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

Pythonのunittest.mock.patchは「既存のクラス・関数を実行時に強制的に書き換える」アプローチのため、事前にインターフェースを設計しなくても後からテスト容易性を後付けできる柔軟さがあります。一方でGoは「最初からインターフェースとして依存を表現する」ことを前提にした設計を要求します。この違いは、Goが静的型付け・コンパイル時検査を重視する言語であることの表れです。

🏆 実務での使いどころ

• 外部サービス（決済API・メール配信・通知基盤）への依存を持つ全てのビジネスロジック: 今回のメール送信のように、実際のネットワークI/Oが絡む処理は、インターフェース越しに抽象化しておかないとCI環境で高速・安定したテストが書けません
• DB層の抽象化（Repository パターン）: UserRepositoryインターフェースを定義し、本番では*sql.DBを使う実装、テストではメモリ上のmapを使う実装を注入する、という同じパターンがDBアクセスにも直接応用できます
• 段階的な実装差し替え: 「まずSMTP直叩きでリリースし、後でSendGrid APIに切り替える」というような技術選定の変更を、EmailSenderを実装するインターフェースの背後に隠しておけば、呼び出し側（OrderService）のコードを一切変更せずに実現できます
• 時刻・乱数など「テストのたびに結果が変わる」依存の注入: time.Nowやrandのような非決定的な依存も、同じ考え方（関数型やインターフェースとして注入する）でテスト可能にできます

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: 今回のEmailSenderに加えてOrderRepository（注文の永続化）インターフェースも導入し、ConfirmOrderが「メール送信」と「注文保存」の両方に依存する設計に拡張してみましょう。複数の依存を持つ構造体でのDIパターンの練習になります
• 次回予告: Day 027 — HTTPサーバー実装（net/http）（実装）。今日学んだインターフェース設計とDIの考え方を土台に、net/httpのハンドラ・ミドルウェアの基本形を学びます。ハンドラの中で今回のようなOrderServiceを呼び出す構成にも触れる予定です

🎯 自己評価

自分の回答

気づき・メモ