Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/naitoyuma7110/tdd-bootcanp

Java Springで「見てわかるテスト駆動開発」を実践
https://github.com/naitoyuma7110/tdd-bootcanp

spring tdd-java

Last synced: 15 days ago
JSON representation

Java Springで「見てわかるテスト駆動開発」を実践

Awesome Lists containing this project

README 

        
## Java Springで「見てわかるテスト駆動開発」を実践

FizzBuzzを題材にTDDを実践



こちらを参考に実践しました  

参考動画：[TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング(Youtube)](https://www.youtube.com/watch?v=Q-FJ3XmFlT8)



![image](https://github.com/naitoyuma7110/TDD-BootCanp/assets/128150297/e6f99eb6-dd0b-49a4-ab82-c6a257cee0c6)



動画内容のソース：[テスト開発駆動](https://www.amazon.co.jp/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA-Kent-Beck/dp/4274217884)



以下メモ



## テスト駆動開発の目的



> Clean code that works  

> 動作するきれいなコード






## TDD のサイクル



1. 目標を考える(Todo リスト)

2. 目標を示すテストを書く

3. そのテストを実行して失敗させる(Red)

   - コンパイルエラー

   - テストの失敗

4. 目的のコードを書く

5. 2 のテストを成功させる(Green)

6. テストが通る状態でリファクタリングを行う(Refactor)

7. 1-6 を繰り返す






- **_優先度を決める_**：テスト容易性と重要度  



  重要度と容易性は必ずしも比例しない



- **_リファクタリングとは_**



  従来の定義:  

  外部から見た振る舞いが変わらないまま、内部のコードを書き換える



  TDD において:  

  成功しているテストが成功しているままでプロダクトコードとテストコードを書き換える  

  

  

  ->「振る舞いの変化」というあいまいな部分を「テストの成功」という明確な基準に置き換えた



## FizzBuzz で TDD の実践



→ どのようにテストを設計するか？



  「仕様をテストに落とし込む」「テストコードと仕様を一致させる」



## テストコードの構成



1. 準備(given)

2. 実行(when)

3. 検証(then)



> テスト駆動開発はゴール(重要なこと)から書く  

> 検証 -> 実行 -> 準備



## テストは動作するドキュメント



1. 検証から書く  

   検証される期待値は具体的な値である必要がある  

   → あいまいな定義,認識では手が止まる  

   

   

    **_この認識の甘さに,より早く遭遇した方が良い(遅いほどロスが大きい)_**



2. 実行を書く  



   **_作成より先に使用する_**  

   

   

   作っていないクラス、メソッドを使う → 使いやすさ >>> 作りやすさ



   - 作りやすさを優先し,使い勝手が悪い実装を防ぐ

   - 使い手側が関知する必要のない作り手側の事情は含ませない



3. 準備をする  

   **_テスト間の依存関係は回避する！_**  

   例）A テストで準備した内容を B テストで呼び込むみ利用するなど



## テストコードのバグはどうやって調べるの？



×「テストのテストを書くの？」



○ **_ディフェクトインサーション_** :テストに意図的に判別可能な誤りを入れる



テストをわざと失敗させ,その結果からテストの整合性を判断する  

(意図的にグリーンをレッドにする)  

## 仮実装



*特定の値で*テストをグリーンにする(_仮実装_)



Q. テストを崩してもコストがかからないタイミングはどこか？  

A. コンパイルを通し仮実装を行いとりあえずテストを通した段階  



→ **_テストコードのバグ検証は仮実装の段階で行う_**



## 三角測量



テストがたまたま通過したということが起こらないよう２つ以上の値を使用しテストを書く。  



仮実装の段階では,特定の値しかテストをパスしないため三角測量によるテストは失敗する



## TDD サイクルの実際



- **_最初のサイクル_**  

  設計の比重が大きい.テストをテストしやすい(ディフェクトインサーション)段階  

  その代わり,実装が未熟でリファクタリングを要する



- **_不安と自信の度合に応じて歩幅を調整する_**  



  - テスト -> 仮実装 -> 三角測量 -> 実装

  - テスト -> 仮実装 -> 実装

  - テスト -> 明白な実装



- **_重複に対するリファクタリング_**



  - Product の重複をリファクタリングする  

    3 つ目の重複で修正(3out)  

    2 つ目の重複で修正(2out)



- **_テスト構造とリファクタリング_**

  - 余分なテストは余分なメンテナンスコストを要する

  - 作成者の都合によるテスト構造の見直し

  - 余分なテストの削除



- アサーションルーレット  

   assert を複数並べるNG パターン(どの検証が失敗したか判別するのにコストを要す)