LoginSignup
0
1

【技術書感想】テスト駆動開発

Last updated at Posted at 2023-09-27

読んだ技術書紹介

テスト駆動開発
スクリーンショット 2023-09-27 0.50.06.png

筆者について(wiki引用)

Kent Beck

  • エクストリーム・プログラミング (XP) の考案者
  • アジャイルマニフェスト起草者の一人
  • デザインパターン、テスト駆動開発、Smalltalkに関する本を執筆
  • ウォード・カニンガムと一緒にCRCカードを普及させた
  • エーリヒ・ガンマと共同でJavaのユニットテストのフレームワークJUnitを開発

テスト駆動開発の概要

テスト駆動開発とは

テストで駆動する開発のこと。TDDと呼ばれる。
テストを作成してから、そのテストが通るようにコードを作成する。
実際には以下のルールで実装していく。

  • 自動化されたテストが失敗した時のみ、新しいコードを書く
  • 重複を除去する

テスト駆動開発で得られること

テスト駆動開発のゴールは「動作するきれいなコード」である。

  • 開発が予測可能になる。完成したかがわかり、バグが残っている心配をする必要もない。
  • コードが伝えようとしているところを余すこと無く受け取れる。最初に思いついたコードを書きなぐるだけではなく、再考してより良いコードを書くチャンスを得られる。
  • あなたが作るソフトウェアのユーザーを快適にする。
  • チームメイトはあなたを信頼し、あなたもまたチームメイトを信頼する。
  • 書いていて気持ちがいい。

テスト駆動開発の進め方

以下の1-3(レッド→グリーン→リファクタリング)を小さなステップで繰り返し実施していくこと。

  1. レッド:動作しない、おそらく最初のうちはコンパイルも通らないテストを書く
  2. グリーン:そのテストを迅速に動作させる。このステップでは罪を犯しても良い
  3. リファクタリング:テストを通すために発生した重複を全て除去する

上記でやることは以下である。

  1. テストを書く

    • 物語には、正しい答えを導くための要素を全て盛り込む
  2. 動かす

    • テストが全て通っている(コードが汚くなってもOK)
    • 複雑なら、TODOリストにまとめておく
    • なにがなんでも速やかにバーをグリーンにする
  3. 正しくする

    • 「動かす」の行いを悔い改める
    • 邪道な部分を除去して、正道に

テスト駆動開発を進めるときのコツ

  • TODOリストを活用する
    • やるべきことを忘れない
    • 目の前の仕事に集中できる
    • 仕事が終わったかもわかるようになる
  • やりたいことが複雑だったり、途中でやりたいことが増えた場合はTODOリストに詰めること。
    途中であれこれ手を出すと1つのテストをグリーンにすることに集中できず、レッド期間が長くなってしまう。
  • 小さなステップを踏むように意識して、10-30分くらいで1回のレッド→グリーン→リファクタリングを回せるようにする。
  • 目的は小さなステップを踏むことではなく、踏み続けることなので、常に細かいステップを踏むべきというわけではなく、複雑な内容の場合に小さなステップを踏めるようになることが大事。
  • 速やかにグリーンにするためのTDD戦略は実装時に仮実装・明確な実装・三角測量といった手法を適切に使い分けること。
    • 仮実装: ベタ書きの実装から、徐々に正しい実装に寄せていく
    • 明確な実装: 正しいと思う実装をいきなり書いて、テストが通ることを祈る
    • 三角測量: 1つのテストではリファクタリングしにくい場合に、もう一つテストを書いて両方が通るようにリファクタリングする

本書でやったこと

3部構成になっている。

  • 1部: レポート機能を多国通貨に対応させる過程をTDDを用いて体験できる。
  • 2部: xUnitのアーキテクチャをpythonで解説されていく。テスト駆動開発に使うツールの実装の説明もテストから駆動され、テスティングフレームワークが自分で描けるようになる。
  • 3部: TDDの「ベストヒット」パターン集。TDD特有のテクニックから、デザインパターン、リファクタリングについても含まれている。

所感

もともとテストを書くことが重要なことは認識していましたが、本書を読んだことで「テストを書かないことはとても勿体無い」と感じ、よりテストを書くことがなぜ重要なのかというところを深く理解できました。実際にテストを書くことで実装への自信や周りからの信頼は向上すると思いますし、テストを先に書くことで実装したいことが明確になったり、テストの書き忘れがなくなったり良いことは多いのかなと思いましたので、一度TDDを実践してみようと思いました。
ただ、実際の業務においては工数や納期があり、どうしてもTDDを意識することが困難な場合も考えられます。そういった場合でも、TDDの本質としては不安を解消してコードに自信を持てることだと思うので、できる限りテストは書こうと思いますし、余裕が出たタイミングでリファクタリングしつつTDDできるようにシフトしていくのも手なのかなと思いました。

0
1
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
0
1