現在所属しているプロジェクトではclassのメソッド単位のテスト（単体テスト・・・とは言い難い）とAPI単位でのテストを記述して開発を行っております。
テストはpytestを使っております。
複数のメンバーで開発を行っておりますので、マージし、リポジトリにpushされたらdeployする前にjenkinsがテストを自動で実行し、成功したらdeployする、ということをしております。
これについて（現在も進行中ですが）良いことと辛いこと、改善したほうが良いと思っていることをまとめます。
（以下、テキストのみ！）
良いこと
- 安心できる
テストが通るとホッとします。精神的に落ち着きます。これは健全に開発を進めるために重要なことです。
いつも「自分の書いたコードは大丈夫かな？」なんて不安を抱えながら仕事をせずに済みます。
- 早期にバグが発見でき、落ち着いて修正できる
サービスが開始されてから重大なバグが発生するとその対応は迅速かつ正確に行う必要があり、それでも当然ながら評判は下がってしまいます。
しかもその対応をしつつ、次のサービスの準備もしなければなりません。
そんな事態は極力避けたいものです。
テストを書いて、自分のコードがマージされるたびに自動的に実行されることですぐにそのバグが見つかり、余裕がある時期に修正対応ができます。
- 仕様の認識のズレを発見できる
エラーが発生したとき、原因を探っていくうちに仕様のズレに気が付くときがあります。
これもリリースされてから発見されると大変なことになります。
それを早期に発見できることは非常に助かります。
これはマスタデータについても言えます。
エンジニアが想定していなかったデータが作成されたとき、このデータはどういう意図で作成されたものかを確認し、対応をすることができます。
- コードが読める
修正対応をすると、メンバーが書いたコードを読むことができます。
コードレビューは別で行っておりますが、それ以後もコードを読む機会ができ、これによって知識が得られたり、問題点などの発見ができます。
辛いこと
- 時間がかかる
テストの実行時間がだんだん長くなります。特にメソッド単位でのテストは非常に長くなります。
現在全部実行するのに1時間ほどかかります（APIテストは数分ですが）。
これは正しい現象ですが問題でもあります。
現在は修正した箇所のテストを自分の環境で実行し、テストが通ったらjenkinsさんに全部やってもらってます。
- エラーが頻繁に発生する
所属プロジェクトでエラーが発生する要因は主に2つです。
一つはマスタデータの更新によるエラー。もう一つは仕様変更によるエラーです。
後者はたまにですが、前者は頻繁に発生し、対応が正直面倒です。
これは我々が書いているテストがマスタデータに密接に結びついているから発生しているものです。
簡単な例をあげると、IDが1のアイテムを売ったら100円もらえる、というテストを書いたりしてます。「単体テスト」と書かず、クラス単位のテスト、と書いているのはこのためです。
開発中は頻繁にマスタデータが変更されます。
売却金額が変更されたり、そのIDのデータそのものが消えたりします。
その度にマスタデータを確認し、修正をします（それでもエラーが発生し、原因がコードのバグだった、なんてこともあります）。
これはあまり良いことではないと思われますが、具体的な数値で結果を比較することで安心感を得ている恩恵も受けております。
- エラーがずっと発生し続ける時がある
忙しいとなかなか修正に着手することができません。
その結果、ずっとjenkinsさんがエラー通知を送ってくれます。
これではテストを自動化している意味がない、ということで、最低でもAPIテストのエラーが発生したらすぐに修正しよう、という決め事をチームで作りました。
とはいってもクラス単位のテストも極力対応するようにしております。
改善したほうが良いと思うこと
- テストの粒度
テストを書く人によって、単にエラーが発生しないことだけをチェックしてたり、事細かに結果を比較するテストを書いたり、とまちまちです。
プロジェクト立ち上げの際に、この辺の粒度をすり合わせしたほうがいいかもしれません。
まだデータが仮状態の時はプログラムが正常に動くだけのテストを書き、データができてきたら結合テストの粒度のテストを別途作成する、でもいいのかな、と思ったり、いや、そんな時間は作れないか？と思ったり。
- 実行時間の短縮
メソッド単位のテストが1時間ほどかかります。
今は開発中なのでまだ時間はありますが、リリース中にバグが見つかり、その修正を行ったあと、1時間かけてテストをしてから本番に反映、なんて悠長なことはしてられません。
さてどうしたものか。
まとめ
今までの開発を振り返り（まだ開発期間中ですが）、テストは良いぞう～、ということが最終的には言いたかったことです。
辛いことはあります。
テストのメンテ、面倒です。
でもそのテストが通るとハッピーな気分になれます。
リリース後、修正するたびに別のバグが出て・・・なんてことはこのテストがあるお陰で回避できると思えばなんてことはありません。
まだテスト書いてないという方、是非テスト書いてみましょう。
今回はコードの安心確保について書きましたが、次回は性能改善について書こうと思います。
あと、もうちょっと見栄えのいい書き方はないか勉強してきます。