@arimakouyou/spec-workflow-mcp 2.2.7

package/.claude-plugin/skills/tdd-skills-rust/references/advanced-techniques.md

@@ -0,0 +1,205 @@
+# TDD 実践テクニックとアンチパターン
+
+## 実践テクニック
+
+### 仕様の不確実性への対処
+
+問題: 仕様が曖昧で、どうテストを書けばいいか分からない。
+
+対策: 具体例から始める。
+
+```rust
+// 悪い: 抽象的すぎる
+#[test]
+fn calculate_price() {
+    // 何をテストする？
+}
+
+// 良い: 具体的なユースケース
+#[test]
+fn calculate_price_for_single_item_without_discount() {
+    let calculator = PriceCalculator::new();
+    let items = vec![Item { price: 1000 }];
+
+    let total = calculator.calculate(&items);
+
+    assert_eq!(total, 1000);
+}
+```
+
+### レガシーコードへの TDD 適用
+
+1. 既存の振る舞いを保護するテストを書く（特性テスト）
+2. 小さくリファクタリング
+3. 徐々にテストカバレッジを上げる
+
+```rust
+// Step 1: 既存の振る舞いを記録
+#[test]
+fn existing_behavior() {
+    let result = legacy_function(&input_data);
+    assert_eq!(result, expected_output);
+}
+
+// Step 2: trait で依存を抽象化してテスト可能にする
+// Step 3: 新機能は TDD で
+```
+
+### テストが複雑になってきたら
+
+対策:
+1. テストヘルパー関数を作る
+2. Builder パターンを使う
+3. テストを分割する
+
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    fn create_premium_user() -> User {
+        User { id: 1, name: "Alice".into(), is_premium: true }
+    }
+
+    fn create_cart_with_items(user: &User) -> ShoppingCart {
+        let mut cart = ShoppingCart::new(user.id);
+        cart.add_item(ItemBuilder::new().name("Book").price(1000).build());
+        cart.add_item(ItemBuilder::new().name("Pen").price(500).build());
+        cart
+    }
+
+    #[test]
+    fn premium_user_gets_discount() {
+        let user = create_premium_user();
+        let cart = create_cart_with_items(&user);
+
+        let total = cart.calculate_total(&user);
+
+        assert_eq!(total, 1350); // 10% discount
+    }
+}
+```
+
+## TDD のアンチパターン
+
+### 1. テストを書かずに実装
+
+```rust
+// 悪い: いきなり実装
+fn calculate_total(items: &[Item]) -> u64 {
+    items.iter().map(|i| i.price).sum()
+}
+
+// 良い: まずテスト
+#[test]
+fn calculate_total_for_empty_list() {
+    assert_eq!(calculate_total(&[]), 0);
+}
+```
+
+### 2. 大きすぎるステップ
+
+```rust
+// 悪い: いきなり完璧を目指す
+#[test]
+fn complete_order_system() {
+    // カート、決済、在庫管理、メール送信...全部
+}
+
+// 良い: 小さく分割
+#[test]
+fn create_empty_cart() {
+    let cart = ShoppingCart::new();
+    assert!(cart.is_empty());
+}
+```
+
+### 3. テストのためのテスト
+
+```rust
+// 悪い: 自明すぎる（getter のテスト）
+#[test]
+fn getter() {
+    let user = User { name: "Alice".into() };
+    assert_eq!(user.name, "Alice");
+}
+
+// 良い: 振る舞いをテスト
+#[test]
+fn user_full_name() {
+    let user = User { first_name: "Alice".into(), last_name: "Smith".into() };
+    assert_eq!(user.full_name(), "Alice Smith");
+}
+```
+
+### 4. プライベート関数のテスト
+
+```rust
+// 悪い: 内部関数を直接テスト
+#[test]
+fn internal_calculation() {
+    assert_eq!(internal_helper(5), 10); // pub(crate) にして無理やりテスト
+}
+
+// 良い: 公開 API を通してテスト
+#[test]
+fn public_method_that_uses_internal() {
+    let obj = MyStruct::new();
+    assert_eq!(obj.calculate(5), expected_result);
+}
+```
+
+Rust ではモジュール内テスト (`#[cfg(test)] mod tests`) からプライベート関数にアクセスできるが、
+公開 API を通してテストする方が設計上望ましい。
+
+### 5. テストの相互依存
+
+```rust
+// 悪い: テストが順序に依存（static mut 等）
+// 良い: 各テストが独立
+#[test]
+fn create_cart() {
+    let cart = ShoppingCart::new();
+    assert!(cart.is_empty());
+}
+
+#[test]
+fn add_item() {
+    let mut cart = ShoppingCart::new(); // 毎回新規作成
+    cart.add_item(Item { price: 100 });
+    assert_eq!(cart.item_count(), 1);
+}
+```
+
+## TODO リストの活用
+
+実装中に思いついたアイデアを記録:
+
+```markdown
+## TODO
+- [x] 空のカートの合計は0
+- [x] 1つの商品を追加した場合の合計
+- [ ] 複数の商品を追加した場合の合計
+- [ ] 割引適用時の合計
+- [ ] 負の価格の商品は追加できない（エラー）
+- [ ] 在庫がない商品は追加できない
+```
+
+メリット:
+- 今やるべきことに集中できる
+- 進捗が可視化される
+- 実装漏れを防げる
+
+## まとめ
+
+やるべきこと:
+- 小さいステップで進める
+- 具体例から始める
+- TODO リストを活用
+- テストヘルパーで整理
+
+避けるべきこと:
+- テストを飛ばす
+- 大きすぎるステップ
+- プライベート関数のテスト
+- テストの相互依存

package/.claude-plugin/skills/tdd-skills-rust/references/green-strategies.md

@@ -0,0 +1,166 @@
+# Green の3つの戦略
+
+テストを最速で通すための3つの戦略と使い分け。
+
+## 1. 仮実装（Fake It）
+
+最も安全な方法。まず定数を返してテストを通す。
+
+```rust
+#[test]
+fn empty_cart_total_should_be_zero() {
+    let cart = ShoppingCart::new();
+    assert_eq!(cart.total(), 0);
+}
+
+// 仮実装
+impl ShoppingCart {
+    fn total(&self) -> u64 {
+        0 // まずは定数で仮実装
+    }
+}
+```
+
+### 使うべき場面
+- 実装方法がまだ明確でない時
+- 複雑な処理が必要な時
+- TDD に慣れていない時
+
+### メリット
+- 最も安全で失敗しにくい
+- 小さいステップで確実に進められる
+- 思考を整理する時間ができる
+
+## 2. 三角測量（Triangulation）
+
+複数のテストケースから一般化を導く。
+
+```rust
+// Test 1: 空のカート
+#[test]
+fn empty_cart_total_should_be_zero() {
+    let cart = ShoppingCart::new();
+    assert_eq!(cart.total(), 0);
+    // 実装: return 0
+}
+
+// Test 2: 商品1つ追加（ここで仮実装から一般化）
+#[test]
+fn one_item_cart_total() {
+    let mut cart = ShoppingCart::new();
+    cart.add_item(Item { price: 100 });
+    assert_eq!(cart.total(), 100);
+}
+
+// 一般化した実装
+impl ShoppingCart {
+    fn total(&self) -> u64 {
+        self.items.iter().map(|item| item.price).sum()
+    }
+}
+```
+
+### 使うべき場面
+- どう一般化すべきか不明確な時
+- 複数のテストケースから共通パターンを見つけたい時
+
+### プロセス
+1. 最初のテストで仮実装（定数を返す）
+2. 2つ目のテストを追加
+3. 両方のテストが通るように一般化
+4. 必要に応じて3つ目、4つ目...
+
+## 3. 明白な実装（Obvious Implementation）
+
+最も高速だが、慣れが必要。いきなり正解を実装。
+
+```rust
+#[test]
+fn total_calculates_sum_of_item_prices() {
+    let mut cart = ShoppingCart::new();
+    cart.add_item(Item { price: 100 });
+    cart.add_item(Item { price: 200 });
+    assert_eq!(cart.total(), 300);
+}
+
+// 明白な実装（仮実装を経ずに直接実装）
+impl ShoppingCart {
+    fn total(&self) -> u64 {
+        self.items.iter().map(|item| item.price).sum()
+    }
+}
+```
+
+### 使うべき場面
+- 実装方法が明白な時
+- シンプルな処理の時
+- TDD に慣れている時
+
+### 重要な注意
+明白だと思って実装したがテストが通らない場合は、躊躇なく仮実装に戻る。
+
+## 戦略の使い分けフローチャート
+
+```
+実装は明白か？
+  ├─ Yes → 明白な実装を試す
+  │         ├─ 成功 → 完了
+  │         └─ 失敗 → 仮実装に戻る
+  │
+  └─ No → 仮実装から開始
+            ├─ テストが1つ → 仮実装のまま
+            └─ テストが複数 → 三角測量で一般化
+```
+
+## 実践例: フィボナッチ数列
+
+### ステップ1: 仮実装
+
+```rust
+#[test]
+fn fib_0() {
+    assert_eq!(fib(0), 0);
+}
+
+fn fib(_n: u64) -> u64 {
+    0 // 仮実装
+}
+```
+
+### ステップ2: 三角測量
+
+```rust
+#[test]
+fn fib_1() {
+    assert_eq!(fib(1), 1);
+}
+
+fn fib(n: u64) -> u64 {
+    if n == 0 { return 0; }
+    1 // まだ仮実装
+}
+```
+
+### ステップ3: さらに三角測量
+
+```rust
+#[test]
+fn fib_2() {
+    assert_eq!(fib(2), 1);
+}
+
+fn fib(n: u64) -> u64 {
+    if n <= 1 { return n; }
+    fib(n - 1) + fib(n - 2) // ここで一般化
+}
+```
+
+## まとめ
+
+| 戦略 | 速度 | 安全性 | 推奨レベル |
+|------|------|--------|-----------|
+| 仮実装 | 遅い | 高い | 初心者〜上級者 |
+| 三角測量 | 中間 | 高い | 中級者〜上級者 |
+| 明白な実装 | 速い | 低い | 上級者 |
+
+原則: 迷ったら仮実装。慣れたら明白な実装。複雑なら三角測量。

package/.claude-plugin/skills/tdd-skills-rust/references/tdd-and-design.md

@@ -0,0 +1,215 @@
+# TDD と設計
+
+## TDD は設計手法でもある
+
+TDD を実践すると、自然に以下の設計原則が守られる:
+
+1. **YAGNI（You Aren't Gonna Need It）**: 必要最小限の実装
+2. **単一責任の原則**: テストしやすい構造体は責任が明確
+3. **依存性逆転の原則**: テストダブルを使うと自然に trait 設計
+4. **疎結合**: テストしやすいコードは結合度が低い
+
+## テストしやすい設計
+
+### テストしにくい設計
+
+```rust
+struct OrderService;
+
+impl OrderService {
+    fn process_order(&self, order_id: i64) -> Result<(), AppError> {
+        // DB に直接アクセス
+        let mut conn = PgConnection::establish("postgres://...")?;
+        let order = orders::table.find(order_id).first(&mut conn)?;
+
+        // 外部 API を直接呼び出し
+        let client = reqwest::blocking::Client::new();
+        client.post("https://payment.api/charge").json(&order).send()?;
+        Ok(())
+    }
+}
+```
+
+問題点:
+- DB が必要（遅い）
+- 外部 API が必要（不安定）
+- テストが環境に依存
+
+### テストしやすい設計
+
+```rust
+// trait で依存を抽象化
+trait OrderRepository: Send + Sync {
+    fn find_by_id(&self, id: i64) -> Result<Order, DbError>;
+}
+
+trait PaymentGateway: Send + Sync {
+    fn charge(&self, amount: u64) -> Result<PaymentResult, PaymentError>;
+}
+
+// 依存性注入
+struct OrderService {
+    order_repo: Box<dyn OrderRepository>,
+    payment: Box<dyn PaymentGateway>,
+}
+
+impl OrderService {
+    fn new(
+        order_repo: Box<dyn OrderRepository>,
+        payment: Box<dyn PaymentGateway>,
+    ) -> Self {
+        Self { order_repo, payment }
+    }
+
+    fn process_order(&self, order_id: i64) -> Result<(), AppError> {
+        let order = self.order_repo.find_by_id(order_id)?;
+        self.payment.charge(order.amount)?;
+        Ok(())
+    }
+}
+```
+
+テスト:
+
+```rust
+#[test]
+fn process_order_charges_payment() {
+    let mut mock_repo = MockOrderRepository::new();
+    mock_repo.expect_find_by_id()
+        .returning(|_| Ok(Order { id: 1, amount: 5000 }));
+
+    let mut mock_payment = MockPaymentGateway::new();
+    mock_payment.expect_charge()
+        .with(mockall::predicate::eq(5000))
+        .returning(|_| Ok(PaymentResult::Success));
+
+    let service = OrderService::new(
+        Box::new(mock_repo),
+        Box::new(mock_payment),
+    );
+
+    assert!(service.process_order(1).is_ok());
+}
+```
+
+## TDD がもたらす設計上の利点
+
+### 1. インターフェース（trait）の明確化
+
+テストを先に書くことで、使いやすい API が設計される。
+
+```rust
+// テストから始めるので、シンプルで直感的な API になる
+#[test]
+fn cart_add_item() {
+    let mut cart = ShoppingCart::new();
+    cart.add(Item::new("Book", 1000));
+    assert_eq!(cart.total(), 1000);
+}
+```
+
+### 2. 責任の分離
+
+テストが複雑になる = 構造体が複雑すぎるサイン。
+
+```rust
+// 責任が多すぎる → テストが複雑
+struct OrderProcessor { /* 在庫確認 + 決済 + メール + 配送 */ }
+
+// 責任を分離 → テストが簡単
+struct OrderProcessor {
+    inventory: Box<dyn InventoryService>,
+    payment: Box<dyn PaymentService>,
+    notification: Box<dyn NotificationService>,
+    shipping: Box<dyn ShippingService>,
+}
+```
+
+### 3. 疎結合
+
+trait を使うことで、自然に疎結合になる。
+
+```rust
+// 密結合（テストしにくい）
+impl UserService {
+    fn create_user(&self, email: &str) -> Result<User, AppError> {
+        let mut conn = PgConnection::establish("...")?; // 直接生成
+        // ...
+    }
+}
+
+// 疎結合（テストしやすい）
+impl UserService {
+    fn new(repository: Box<dyn UserRepository>) -> Self {
+        Self { repository } // 注入
+    }
+}
+```
+
+## テスタビリティの原則
+
+### 1. 外部依存を注入する
+
+```rust
+// テストしにくい: 時刻を直接取得
+fn generate_report(&self) -> Report {
+    let now = chrono::Utc::now();
+    // ...
+}
+
+// テストしやすい: trait で抽象化
+trait Clock: Send + Sync {
+    fn now(&self) -> DateTime<Utc>;
+}
+
+fn generate_report(&self, clock: &dyn Clock) -> Report {
+    let now = clock.now();
+    // ...
+}
+```
+
+### 2. 副作用を分離する
+
+```rust
+// 副作用が混在
+fn process_and_save(data: &Data, conn: &mut PgConnection) -> Result<Report, AppError> {
+    let result = expensive_calculation(data); // 純粋な計算
+    diesel::insert_into(reports::table).values(&result).execute(conn)?; // 副作用
+    Ok(result)
+}
+
+// 副作用を分離
+fn process(data: &Data) -> Report {
+    expensive_calculation(data) // 純粋
+}
+
+fn save(report: &Report, conn: &mut PgConnection) -> Result<(), DbError> {
+    diesel::insert_into(reports::table).values(report).execute(conn)?;
+    Ok(())
+}
+```
+
+### 3. 決定論的にする
+
+```rust
+// ランダム（再現不可）
+fn generate_token() -> String {
+    use rand::Rng;
+    rand::thread_rng().gen::<[u8; 32]>().encode_hex()
+}
+
+// 決定論的（trait で抽象化）
+trait TokenGenerator: Send + Sync {
+    fn generate(&self) -> String;
+}
+```
+
+## まとめ
+
+TDD を実践すると:
+- trait による抽象化が自然に使われる
+- 責任が適切に分離される
+- 疎結合なコードになる
+- 依存性注入が自然に使われる
+
+TDD = 設計駆動開発

package/.claude-plugin/skills/tdd-skills-rust/references/test-design.md

@@ -0,0 +1,128 @@
+# テスト設計
+
+## 境界値分析（Boundary Value Analysis）
+
+境界付近の値は特にバグが発生しやすい。
+
+### 例: 年齢区分
+
+```rust
+// 0-17: 未成年, 18-64: 成人, 65以上: 高齢者
+
+#[test]
+fn age_17_is_minor() {
+    assert!(is_minor(17));
+}
+
+#[test]
+fn age_18_is_not_minor() {
+    assert!(!is_minor(18));
+}
+
+#[test]
+fn age_64_is_adult() {
+    assert!(is_adult(64));
+}
+
+#[test]
+fn age_65_is_senior() {
+    assert!(is_senior(65));
+}
+```
+
+## 同値分割（Equivalence Partitioning）
+
+同じ振る舞いをするグループに分割してテストケースを削減。
+
+### 例: 割引計算
+
+```rust
+// 0-999: 割引なし
+// 1000-4999: 5%割引
+// 5000以上: 10%割引
+
+use rstest::rstest;
+
+// 各クラスから代表値を選んでテスト
+#[rstest]
+#[case(500, 0)]
+#[case(3000, 150)]
+#[case(10000, 1000)]
+fn discount_representative_values(#[case] amount: u64, #[case] expected: u64) {
+    assert_eq!(calculate_discount(amount), expected);
+}
+
+// 境界値も必ずテスト
+#[rstest]
+#[case(999, 0)]
+#[case(1000, 50)]
+#[case(4999, 249)]
+#[case(5000, 500)]
+fn discount_boundary_values(#[case] amount: u64, #[case] expected: u64) {
+    assert_eq!(calculate_discount(amount), expected);
+}
+```
+
+## テスト命名規則
+
+### パターン1: 英語構造的命名（推奨）
+
+```rust
+#[test]
+fn total_should_be_zero_when_cart_is_empty() { /* ... */ }
+
+#[test]
+fn total_should_increase_when_item_added() { /* ... */ }
+
+#[test]
+fn should_return_error_when_negative_price() { /* ... */ }
+```
+
+### パターン2: 日本語（可読性重視の場合）
+
+```rust
+#[test]
+fn 空のカートの合計金額は0円() { /* ... */ }
+
+#[test]
+fn 商品追加でカートの合計金額が増える() { /* ... */ }
+
+#[test]
+fn 負の価格の商品追加で例外発生() { /* ... */ }
+```
+
+### 命名のポイント
+- テスト名から何をテストしているか分かる
+- 失敗時に原因が推測できる
+- 「対象_条件_期待結果」パターン
+
+## エラーケースのテスト
+
+```rust
+// #[should_panic] を使う方法
+#[test]
+#[should_panic(expected = "division by zero")]
+fn divide_by_zero_panics() {
+    let calc = Calculator::new();
+    calc.divide(10, 0);
+}
+
+// Result を返す方法（推奨）
+#[test]
+fn invalid_email_returns_validation_error() {
+    let result = User::create("invalid-email");
+
+    assert!(result.is_err());
+    let err = result.unwrap_err();
+    assert!(matches!(err, AppError::Validation(msg) if msg.contains("email")));
+}
+```
+
+Result を返すパターンの方が Rust では一般的。`#[should_panic]` は panic が意図された場合のみ使用する。
+
+## まとめ
+
+- 境界値は必ずテスト
+- 同値分割で効率化
+- 明確な命名
+- エラーケースは Result ベースで検証