1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

テスト駆動開発「第1部 多国通貨 14章~17章」のまとめ

Last updated at Posted at 2017-12-25

https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

現在友人達とテスト駆動開発の本を輪読してます。
自分の担当ぶんの「第1部 多国通貨 14章~17章」の内容をアウトプットとしてまとめます。

本には実際のコードも掲載されているのですが、そちらは章続きの内容になっていてこのパートの部分だけ抽出してもよくわからないので割愛します。

同じく輪読されている方がいますので、今までの章については下記記事をみるとわかります。
下記記事にも書いてありますが、実際のコードを見たい方は書籍を購入されると良いと思います。(Java / JUnitです)
http://tf6533.hateblo.jp/entry/2017/12/18/135510

学習用テストと回帰テスト

1. シンプルな実装を心がける。複雑に考えすぎず、今やるべきことをそのままテストに書く

TDDの基本を忘れない。まずはテストを通すことを優先する。

2. その後、処理の抽出などのリファクタリングを行ってテストを完成させていく

テストを書いている間に処理に悩むようなことがあったら、学習用テストを記述して検証する。実装内部だけで使うヘルパークラスなどを新たに作成する場合は、開発メンバーとの足並みによってそのクラスのテストを書くかどうか判断する

3. リファクタリングをしている間、予期せぬ不具合が出た場合は**回帰テスト(退行テスト)**を記述して、不具合を再現・特定する

学習用テスト

API、言語の仕様が期待通りに動くかを確認するためのテスト。プロダクトで使ったことのない新しい機能や、パッケージの新機能などが正常に動くかどうかを確認する。このテストが通らなければ、既存のプロダクトコードでのテストも必然的に通らないことがわかる。

回帰テスト/退行テスト

不具合、ミスが発見されたときに状況を再現してどこで不具合が起きたのかを確認するためのテスト。

テスト任せとコンパイラ任せ

1. まずはこうなったら良いというテストを書く

2. 修正が必要な場合は抽象度を落として、より具体的なテストを書いてまず動作させる

3. 連鎖的な修正を避けるため、依存の終端(ゴール)から書き始め、頂点(テストケース)まで到達させる

変更ごとにテストを動かし、グリーンであること(コントローラブルであること)を確かめながら先へ進む

4. コンパイルエラーが出たら、それをTODOリスト代わりにして修正作業を行う

最終的にコンパイラに従って修正していけば連鎖的な修正がすべて収まるようなところまで持っていく

将来の読み手を考えたテスト

将来、自分以外がこのコードを読むことを考えながらテストを書く。
今自分が考えていることを、将来の書き手に使えるための役割をテストに担ってもらう。
テストを書くときには、読者のことを考えながら書くのが何より大事。

これまでのプログラミングスタイルとTDDの比較・計測を自分自身で行い、TDDのメリットを活かせるようにする

コーディングの時間だけでなく、デバッグ・結合・人への説明(PJメンバー・開発メンバーなど)に要する時間もしっかり考慮に入れる

多国通貨の全体ふりかえり

  • 各章でのプロセスを経て作った成果物のふりかえりの章

ここから先はどうなるのか?

TODOリストが終わったらコードを批判的に見てみる。改良箇所はまだまだ多数。TODOが空になったら設計を見直す良いタイミングなので、齟齬がないか、テストは足りているか(意図した/期待した通りの結果になっているか)、重複はないかなど、新たな設計の必要性がないか考えてみる

メタファー

実際の式・クラスの使われ方に応じてその都度最適化していくことで、コードはよりきれいになる。

テスティングフレームワークの使用状況

テストの実行は何回だったか、実行間隔はどれくらいかを計測する。例えば間隔が長かった場合はどのような要因で長くなったのか、などをふりかえっていく。筆者は純粋にコードを書いていたときは1分に1回テストを実行していた。

コードメトリクス

クラス、メソッドの数はどれくらいか?
行数はどれくらいか?
条件式やループが深すぎて複雑になりすぎていないか?(循環的複雑度が高すぎないか?)

プロセス

一連のプロセスにどれくらいの変更が必要になっているか?

  1. 小さいテストを追加
  2. 全てのテストを動かし、失敗することを確認
  3. 変更
  4. 再び全てのテストを動かし、成功することを確認
  5. リファクタリング

テスト品質

代表的な計測手法

  1. ステートメントガバレッジ(網羅的なテスト)
  2. 欠陥挿入(プロダクトコードの任意の行の意味合いを変え、わざとテストコードを失敗させる)
カバレッジを上げる方法

より多くのテストを書くことでカバレッジは上がるが、テストを増やすことによって全ての入力の組み合わせを担保するのではなく、同じテストのままでコードを減らすことによってより多くの組み合わせをカバーする(ロジックをシンプルにする)ことでもカバレッジは上がる

最後のふりかえり

  1. テストをきれいに機能させるアプローチは、仮実装・三角測量・明白な実装
  2. テストとコードの間の重複除去が、設計を駆動する
  3. TDDを回していると、テスト間のギャップを制御する能力がつく
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?