仕様変更で死なないためのユニットテスト

仕様変更で死なないため
のユニットテスト

d:id:gnarl(team-lab, inc.)

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

あるユニットテスト

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

自動化されたテストによ
る死亡フラグの回避
●
巨大なシステムは小さい機能の
集成である
● 小さい機能を個別に自動でテス

トする
●
コードを変更するたびに自動でテ
スト可能

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

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

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

上がる

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

タルヘルスが悪化

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

しなければいけないのか明確になる
● 安心してコードが書ける

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

Empfohlen