巨人の足元でたじlog

そうして言葉を軽んじるから――― 君は私の言葉を聞き逃す

pythonではじめるソフトウェアアーキテクチャ読書メモ③

3章テスト容易性

テストは書いたほうがいい。それだけはわかっていながらも、雰囲気で理解していてちゃんとしたテストを書くことを先延ばしにしてきた。(というよりはテストを書く必要性に迫られなかった。)

ちゃんとテストの意義や方法論を理解しておきたい。

テストの種類

実際に自分が一番やってきたことといえば、パフォーマンステストくらいだ。そうか、あれも一種のテストだったんだな。
テストコードを書く機能テストだけがテストなのかと思いこんでいたが、様々な観点からテストをする必要があるんだな。ふむ。

テストの戦略

複雑さの削減

  • 結合度を下げる
  • 凝集度を上げる
  • 明確なインターフェースを用意する
  • クラスの複雑さを減らす

なるほど、ここらへんはコードを読みやすくすることだったり、修正を容易にすることに加えてテストを容易にすることもモチベーションになるんだな。

予測可能性の改善

予測可能性を上げるポイント - 正しい例外処理 - 無限ループやデッドロック - 時間に依存する処理 - 並列処理 - メモリ管理

確かに今までコードを書いていて、厄介なポイントだったりするのはこのあたりだった気もする。
そのあたりをこうして体系的に整理できるのはありがたいな。
この中でも特に正しい例外処理についてはちゃんとした設計方法をわかっていない。 このあたりも後々体系的に整理する必要がありそうだ。

外部依存の制御と分離

データソースに関するテクニック

  • データを記述したローカルファイルの使用
  • インメモリデータベースの使用
  • テストデータベースの使用

SQLiteがよく使われると言っていたが、職場の人いわく、SQLiteはjoin?だかのクエリを投げたときに微妙に挙動がおかしくなる的なことを言っていた気がするので、複雑なテストを書くときにはあまり使えないかもしれない。

リソースの仮想化に関するテクニック

  • スタブ
  • モック
  • フェイク

モックとスタブの違いについて、スタブはデータを用意するパーツで、モックはデータを投げる受け先という認識だったのだが、これは合っているのか?
定義だけをあれこれこねくり回してもしょうがない。
実際に書くことになってから改めて名前は確認することにしよう。

今日はここまで。テストについてちょっとだけ理論入りました。