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

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

「レガシーコードとは、テストのないコードである」

●｢テスト｣とは、Excelに書かれたテスト仕様書のことではない

●全自動で実行できる、再現性のあるユニットテスト

なぜ、レガシーコードに対するあらゆる変更は死亡フラグ

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

自動化されたテストによる死亡フラグの回避

●巨大なシステムは小さい機能の集成である

●小さい機能を個別に自動でテストする

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

自動化テストで仕様変更に立ち向かう

●最初に仕様を満たすテストを書く●テストをパスするようなコードを書く

●テスト=機械で検証可能な仕様

テストはいかにしてソフトウェアの品質を向上するか●バグが出たらまず再現するテストを書く–同じバグが出たら即座に検出可能

●自動化テストはすばやく、何度でも実行可能–自分の変更がソフトウェアを壊していないことを常に確かめられる

テストはいかにしてソフトウェアの品質を向上するか●自動化テストを書くためには、テストしやすい設計になっていないといけない

●テストしやすい設計=シンプルで再利用可能な設計

●テストを書くだけで設計の品質が上がる

レガシーコードは

ハラスメントである

●整備されていないテスト=コード変更に苦痛を伴う

●ひどい設計のコード=読むだけでメンタルヘルスが悪化

自動化されたテストによる精神の安定

●コードの変更に対してすばやいフィードバックが得られる–リファクタリングも安心

●設計がクリーンに保たれる●最初にテストを書くことで、何を実装しなければいけないのか明確になる

●安心してコードが書ける

まとめ

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