SSブログ

テストファースト開発(2) [プログラマー現役続行]

以前、「テストファースト開発」と題して、当時どのように開発していたかを書いています。その中で開発のフローについて、次のように書いています。各ステップの解説については、前述のブログを読んでください。
  1. 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述
  2. 既存のAPIの実装の調査(新たなAPIの場合には似たAPIの実装の調査)
  3. テストコードの作成
  4. 機能の実装
  5. リファクタリング
今週は、あるマイクロサービスの機能の一部を別のマイクロサービスへ移行する作業をしました。機能そのものは小さかったのですが、実際に行ったことは、次の通りです。

API仕様の確認

最初に、API仕様、つまりgRPCの.protoに書かれているrpcの仕様を確認しました。仕様を読んで、疑問に思うことが何点かありました。つまり、仕様から読み取れない振る舞いがあった訳です。それで、既存の実装コードを調べたり、既存のe2eテストを修正して試したりして、不明な振る舞いの動作を確認しました。

確認した内容のすべてをもとの.protoファイルに記述するPR(Pull Request)を作成し、もとの開発者にレビューをお願いしました。私が調査から読み取れていなかった点の指摘があったので、指摘点を修正して、PRをapproveしてもらい、マージしました。.protoファイル内にコメントして記述されている仕様の修正なので、特に実装の変更はありません。

テストコードの作成

もとのマイクロサービスにあったe2eテストを参考に、修正されたAPI仕様に書かれていることをすべて網羅するのを確認しながら、新たなe2eテストを作成して、すべてのテストが失敗するのを確認しました。

実装

テストが合格するように順次実装していくのですが、まだ実装していない箇所にコードが到達した場合には、panicするかUnimplementedエラーを返すようにコードを入れながら実装していきます。テストがすべて合格するまで、実装を行っていきます。

すべてのテストが合格したら、テストによって実際に実行されたコードをカバレッジで確認します。ここで重要なのは、カバレッジのパーセントではなく、実装したコードがすべて実行されたかです。私個人としては、「開発者はカバレッジのパーセントではなく、実行されたコードを確認することが重要」と思っています。

確認してみると、実際に起きたらInternalエラーになるコードが実行されていないことが判明しました。Internalエラーは、設計上想定していないことが起きていることを意味しますので、そのエラーをテストで起こせるかどうかは、内容次第となります。今回は、テストコードで起こせるものだったので、追加のテストコードを作成しました。

この追加のテストコードは、すでに実装が書かれているので、合格するテストを最初から書いてしまうと単に合格してしまいます。それでは該当コードが実行されたことによって合格しているのか、それとは別の理由で合格しているのか分からなくなってします。それで、わざと(正しくはない)合格しないテストを書いて、失敗することを確認してから、正しいテストへ修正して、合格することを確認しました。

最後にカバレッジで実行された実装コードを確認して、実装作業は終了です。

コードを見直して、とくにリファクタリングは必要ないと判断し、PRをレビューに出しました。
コメント(0) 

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

※ブログオーナーが承認したコメントのみ表示されます。

Facebook コメント