テストファースト開発 [プログラマー現役続行]
(私自身のテスト駆動開発については、こちらにまとめてあります)
一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。
2.では、既存の実装の作り(構造)とテストコードを調べることになります。新たな機能をどのように作ればよいか、理解できるまで調査します。理解できたと判断したら、3.へ移ります。
3.の開始に際して、修正を行うマイクロサービスの既存のテストのフレームワークでは、私が書きたいテストが書けない場合があります。その場合には、新たなテストフレームワークの構築を行います。実際、メルペイで最初に担当したマイクロサービス用に私が開発したテストフレームワークを導入することが多いです。
3.と4.は実際には繰り返し行っていきます。まず、3.でAPI呼び出しがエラーになることが期待されるテストコードを書きます。そして、期待されるエラーが返ってこない(実際には実装部分には単純に
エラーの実装が終わったら、正常ケースのテストコードを書きます。この時点でも該当する実装部分には、
すべてのテストの作成とその実装が完了したら、コードを見直して、リファクタリングです(5.)。そして、最後にPRのレビューをTech Leadへ依頼することになります。
私自身がテストファーストで開発している主な理由は、短い勤務時間で担当する開発を着実に間違いなく行うためです。私自身は、テストファースト開発を最近始めたのではなく、昔から行っています。しかし、今は強く意識して行っています。
テスト駆動開発とテストファースト開発には、ある程度の規律を必要とします。たとえば、不具合を修正する場合には、原因を調査後に、「再現テストを書いてから実装を修正する」ことが求められます(これも一種のテストファーストです)。本来、そのような規律は、ペアプログラミングなどを通して強制して習慣化させる必要があります。しかし、PRを最後にレビューするという開発スタイルの開発組織では、難しいものがあります。
スポンサーリンク
一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。
開発順序
現在担当しているマイクロサービスは、その開発の当初から私自身が関わっていたものでないため、既存のコードを調査して理解する必要がある場合が多く、開発はおおまかに次の順序となります。- 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述
- 既存のAPIの実装の調査(新たなAPIの場合には似たAPIの実装の調査)
- テストコードの作成
- 機能の実装
- リファクタリング
2.では、既存の実装の作り(構造)とテストコードを調べることになります。新たな機能をどのように作ればよいか、理解できるまで調査します。理解できたと判断したら、3.へ移ります。
3.の開始に際して、修正を行うマイクロサービスの既存のテストのフレームワークでは、私が書きたいテストが書けない場合があります。その場合には、新たなテストフレームワークの構築を行います。実際、メルペイで最初に担当したマイクロサービス用に私が開発したテストフレームワークを導入することが多いです。
3.と4.は実際には繰り返し行っていきます。まず、3.でAPI呼び出しがエラーになることが期待されるテストコードを書きます。そして、期待されるエラーが返ってこない(実際には実装部分には単純に
panic("Not Implemeted Yet")
と書いてあるだけ)のを確認して、4.としてその部分の実装を行います。エラーの実装が終わったら、正常ケースのテストコードを書きます。この時点でも該当する実装部分には、
panic("Not Implemeted Yet")
と書いてあるだけなので、テストが合格しないのを確認して、実装を行います。すべてのテストの作成とその実装が完了したら、コードを見直して、リファクタリングです(5.)。そして、最後にPRのレビューをTech Leadへ依頼することになります。
テストファースト開発について
上記の開発順序は、私個人の開発順序です。実際に、最後のPRのレビュー依頼を行った時点では、テストコードと実装の両方が揃っていますので、どのような順序で開発しているかは分かりにくいです。私自身がテストファーストで開発している主な理由は、短い勤務時間で担当する開発を着実に間違いなく行うためです。私自身は、テストファースト開発を最近始めたのではなく、昔から行っています。しかし、今は強く意識して行っています。
課題
ペアプログラミングがほとんど行われてない職場では、各人がどのような順序で開発しているのかが分かりにくいという問題があります。テスト駆動開発とテストファースト開発には、ある程度の規律を必要とします。たとえば、不具合を修正する場合には、原因を調査後に、「再現テストを書いてから実装を修正する」ことが求められます(これも一種のテストファーストです)。本来、そのような規律は、ペアプログラミングなどを通して強制して習慣化させる必要があります。しかし、PRを最後にレビューするという開発スタイルの開発組織では、難しいものがあります。
お勧め本
僕たちの厳密さの一つの例が、自動化したユニットテストをテスト対象のコードより先に書くというルールだ。たいていのプログラマーはすぐにコードを書きたがる。書き上がれば出来映えに自己満足して、そのコードのために自動テストを書こうという気にはなかなかならないものだ。こういった習慣をやめてしまうのは簡単だろうが、僕たちがコードに期待する品質には極めて重大なものなのだ。テストコードを対象コードの前に書くという規律により、常に守れるようになるわけだ。
リチャード・シェリダン著『Joy, Inc.』(日本語版、p.212)
スポンサーリンク
2019-10-18 08:07
コメント(0)