1. 仕様変更で死なないため
のユニットテスト
d:id:gnarl(team-lab, inc.)

2. 「レガシーコードとは、テ
ストのないコードである」
●
｢テスト｣とは、Excelに書かれた
テスト仕様書のことではない
● 全自動で実行できる、再現性の
あるユニットテスト

3. なぜ、レガシーコードに対す
るあらゆる変更は死亡フラグ
なのか
●
ユニットテストを考慮していない
設計
– フルセットの環境&データを用意する
– ひととおり実行してみる
– 結果を目視で確認する
– バグがあったら修正して繰り返す
– そのうち人間が死ぬ

4. 自動化されたテストによ
る死亡フラグの回避
●
巨大なシステムは小さい機能の
集成である
● 小さい機能を個別に自動でテス
トする
●
コードを変更するたびに自動でテ
スト可能

5. 自動化テストで仕様変更
に立ち向かう
●
最初に仕様を満たすテストを書く
●
テストをパスするようなコードを書
く
● テスト=機械で検証可能な仕様

6. テストはいかにしてソフト
ウェアの品質を向上するか
●
バグが出たらまず再現するテスト
を書く
– 同じバグが出たら即座に検出可能
● 自動化テストはすばやく、何度で
も実行可能
– 自分の変更がソフトウェアを壊していな
いことを常に確かめられる

7. テストはいかにしてソフト
ウェアの品質を向上するか
●
自動化テストを書くためには、テ
ストしやすい設計になっていない
といけない
●
テストしやすい設計=シンプルで
再利用可能な設計
● テストを書くだけで設計の品質が
上がる

8. レガシーコード
は
ハラスメント
である
●
整備されていないテスト=コード変更
に苦痛を伴う
● ひどい設計のコード=読むだけでメン
タルヘルスが悪化

9. 自動化されたテストによ
る精神の安定
●
コードの変更に対してすばやいフィー
ドバックが得られる
– リファクタリングも安心
● 設計がクリーンに保たれる
● 最初にテストを書くことで、何を実装
しなければいけないのか明確になる
● 安心してコードが書ける

10. まとめ
●
自動化されたテストで人間が死
なないソフトウェア開発をしましょ
う