テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA
@t_wadaさんがテスト駆動開発のライブコーディングをやっていて、歩きながら聞いていた。
@t_wadaさんがブツブツつぶやいてくれているので、画面を見なくても、聞くだけで想像できる。
まるで、テスト駆動開発のラジオドラマみたいな感じだ。
Developer eXperience Day CTO/VPoE Conference 2021 - connpass
@t_wadaさんの呟きで面白かった点を記録しておく。
テストプログラムを書いていると、バグ修正とリファクタリングが混じってしまう時がある。
お勧めは、バグ修正だけに注力するか、リファクタリングだけに注力するか、モードを意識的に切り替えること。
思い通りの動きにならない時に、バグ修正とリファクタリングが入り交じるのはお勧めしない。
テストプログラムを書いていくと、テストプログラムがドキュメントそのものになる。
すると、状況の下に機能を置くか、機能の下に状況ごとに書いていくか、どちらかの方針がある。
どちらも正しい。
テストプログラムの観点では、状況の下に機能を書く方が、書きやすい。
状況はグローバル変数として共通化されるので、ソースコードは短くなるので保守性は高くなる。
しかし、機能が直感的に分からないから可読性は低くなる。
一方、機能の下に状況ごとにツリー構造にロジックを書いていくと、テスト仕様書のようになるので読みやすい。
機能のツリー構造は、業務システムアプリとかWebアプリのメニューみたいなものだから、どこに機能があるのか探しやすい。
しかし、状況があちこちに散らばるので、重複したソースコードが多くなり、保守性は下がる。
つまり、テストプログラムの可読性と保守性はトレードオフになる。
どちらが正しい、というわけではない。
テストプログラムを書く人の永遠の問題。
そこで、このトレードオフを緩和するために、パラメトライズド・テストプログラミングのテクニックがある。
つまり、テストメソッドやテストプログラムをパラメータで増やすやり方がある。
これにより、テストプログラムを機能別に書いたとしても、状況をパラメータとして増やすことができて、テストプログラムの可読性を保持するとともに、保守性も高める。
テスト駆動開発がXPで出てきてからもう20年も経つ。
改めて聞いて、色々気づきがあってよかった。
| 固定リンク
「プログラミング」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのモジュールシステムは複雑性をより増している(2022.09.10)
- Javaはなぜ関数型言語になろうとしているのか(2022.09.02)
- Javaのラムダ式の考え方(2022.08.10)
- Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント