Showing 4 Result(s)

レガシーコードからの脱却 まとめ – 11.1 – 11.4

11.1 レッド/グリーン/リファクタリング 内容 テストファースト開発には3つのことなるフェーズがある。 レッド/グリーン/リファクタリング だ。ユニットテストフレームワークの視覚効果が由来する。 レッドテストを失敗「させる」(コンパイルエラーも含まれる)。コンパイルエラーが起きたら「スタブアウト」を作り、テストを失敗させる。 グリーンすべてのテストを成功させる。 リファクタリングコードからリファクタリングし、テストをリファクタリングする 一つのユニットテストを作る中で、この3つのフェーズを繰り返し行っていく。一つのユニットテストというのは、1アサートという意味ではなく、1つのインターフェースに対してかかっている。1インターフェース:複数アサートはあり得る。 11.2 テストコードの例 Parsonという名前と年齢を持つクラスのテストを例にしてテストを解説している。 レッドのフェーズ。クラスが一つも無いところからハッピーパスのテストを書き始める。内容は、Personクラスのコンストラクタに渡した名前と年齢の値がPersonクラスの getName() と getAge() で取得した値と同じかどうかをテストする。クラスは無いのでコンパイルエラーが発生する。 コンパイルエラーのみ解消するために、Personクラスをスタブとしてとして作成してコンパイルエラーの部分を解消。スタブはクイックフィックス機能で作成し、メソッド返却値はダミーのままにすること。テストはコンパイルエラーが解消するので実行すると、返却値がダミーなのでエラーとなる。最初の目的はテストを失敗させることなのでOK。 グリーンのフェーズ。テストが通るようにプロダクトコードを修正する。コンストラクタの引数をメソッドで返すように実装する。 11.3 制約を導入する Personクラスの年齢に負の数を入れると年齢としてはおかしくなるので、そういった不備をなくすために制約を入れる。そういう場合の解説。ここでもテストファーストで書きながら説明している。 Personクラスに最大と最小の定数のテストを書く レッドフェーズ。 Personクラスに最大と最小の定数を記述しコンパイルエラーを出す。 コンパイルエラーをクイックフィックスを使い解消 実行すると失敗するのでレッド完了。 グリーンフェーズ。 Personクラスの最大値、最小値の値を適切に設定して実行。OKとなりグリーン完了。 次にコンストラクタの引数・年齢に最小値より小さい値を入れたらエラーとなるテスト レッドフェーズ 投げられるとOKとなる例外クラスをテストに書いてコンパイルエラーを起こす。 コンパイルエラーの例外クラスはクイックフィックスで作成し、コンパイルエラーを解消。 実行すると失敗するのでレッド完了。 グリーンフェーズ Personクラスのコンストラクタ内で最小値より小さい場合に例外を投げる処理を追加して実行。OKとなりグリーン完了。 次にコンストラクタの引数・年齢に最大値より大きい値を入れたらエラーとなるテスト 最小値のテストと同じ要領で最大値のテストを追加してグリーンまで完了させる。 リファクタリング 最小値と最大値で違う例外を投げるようにしたが、範囲外を表す1つのクラスにした方が使い勝手が良さそうなため、そちらを使うようにする。 11.4 作ったもの 11.2 – 11.3 で作ったものを通しての要点は「テストは仕様であり、テストは不要に重複しないように作る」のがポイントと言っている。 学び テストメソッド名に関する名前重要。何をテストしているかが分かれば、冗長でも構わない。何をテストしているかと仕様がわかることが重要。 コンパイルエラーの解消はクイックフィックスで解消していくことで、コードのタイプミスを減らせる。 レッドのフェーズは、コンパイルエラーからテストを実行して失敗させること。 最大値、最小値などの値よりも定数の名前が重要。境界値は時代の変化に合わせて変わるかもしれないが、重要なのは簡単に変えられるようにしておくこと。 例外をテストする方法。 レッド/グリーン/リファクタリングの3つのフェーズの基本。 テストコードは「失敗をさせ、正しいコードにすることで保証されたものとなる」で、このためにレッド/グリーンのフェーズがある。 …

レガシーコードからの脱却 まとめ – 11

11 プラクティス7 テストでふるまいを明示する 内容 テストによって動くものと動かないものがすぐにわかる。これは開発の原動力を大きく影響を及ぼす。 ケイパー・ジョーンズは「開発者の時間の半分以上が、過去にやった仕事の手直しに費やされている」と言っている。例えば、不具合の原因が2箇所による複合的な要因の場合、その原因を特定するのは非常に時間がかかるが、ありえる。この手直しに時間がかかっていることが、テスト駆動開発を行う理由だ。 マネージャーがテスト駆動開発する時間を持てないというのは、以下のループとなっているためだ。 テスト駆動開発をしていないから、問題の原因の特定に時間がかかる 問題の原因の特定に時間をかけすぎてるから、テスト駆動開発を学習する時間がとれない このループになっているのであれば、ここから降りなければならない。 テストは具体的な要件であり、メソッドの使い方を正しくフォーカスすることができる。これは実装を良くするためや、問題をとりのぞくために非常に効果がある。 学び ほとんどの時間を読む時間、調査する時間に費やしているという事実 テスト駆動開発をしていないからテスト駆動開発ができないループに入っている場合、なんとかしてそのループを抜け出なければならない 学びを活かすアイディア・行動 テストコードの目的のための事前知識整理

レガシーコードからの脱却 まとめ – 10.11

10.11 本章のふりかえり 内容 正しいユニットテストの書き方で書けば、コードのリファクタリングのサポートをしてくれて「CLEAN」なコードにつながる。 テスト駆動開発は正しく行わないと、保守可能な効果はなくなる。 学び 内容の通り 学びを活かすアイディア・行動 特になし

レガシーコードからの脱却 まとめ – 10.10.2

10.10.2 優れたユニットテストのための7つの戦略 内容 ユニットテストのための大切な7つの観点を説明している。 戦略 補足 呼び出し側の視点に立つ 呼び出し側は何を必要としているのか、何を渡す必要があるのか。 テストを使ってふるまいを表す 仕様がわかるドキュメントになるようにわかりやすく書く。テストを最新に保つことが、ドキュメントを最新に保つことになる。 新しい違いを生み出すテストだけ書く テストは一意にする。観察可能なテストにして無駄なテストをなくす。 失敗したテストにパスするためのコードのみを書く まず失敗するコードを書き、テストが通るコードに書き直す。このルールに則った場合に「テストが通ったら正しい」という保証になる。 テストを使って、ふるまいを作る ハッピーパスから作るにしろ、例外からにしろ、テストから作る コードをリファクタリングする 反復開発する場合、保守性は重要だからリファクタリングをして保守可能な状態にする テストをリファクタリングする 実装に依存したテストではなくふるまいを表したテストを書いていなければ不要に修正する必要はない。ただし、テストもコードであるため保守可能な状態にしないとコード品質に影響する可能性がある。 学び テストはコードだという認識。保守可能な状態にリファクタリングする必要がある。 テストはふるまいを表すべき。実装に依存したかたちにしてしまうと不要に修正する必要の可能性が出てくるし、そうなると保守できなくなる。 テストは仕様を表す最新のドキュメント。実行することでプログラムが正しいことを表すため、仕様がわかるように書くことで、最新のドキュメントとなる。メソッドコメントのように変更し忘れがなくなる。 学びを活かすアイディア・行動 現場のユニットテストのコーディング規約づくり