前置き
新卒で、小さな小さな自社パッケージソフト開発の会社に入社。
その後転職してSES企業に入社し、客先常駐エンジニアに転身してもうすぐ３年になります。
３年間の間、複数の案件を渡り歩き、ふとテストコードに関するポエムを書きたくなりました。
そもそもテストコードとは、テストコードを書くべきかとか、テストコードを書く意義、そもそもTDDという手法があってな...といったところは世の中でさまざまに語られているので、ここで私が今更論ずることも無いですが、私個人としてはテストコードは絶対に書くべきだと思っています。
ただ、テストコードを書くと言っても以下まで実践しないとテストコードの効果を最大限発揮できないだろうと考えています。
- テストコードを書く
- テストコードを共有する（Git,SVNにコミットする）
- テストコードをCI/CDの仕組みに乗せてコミット時やリリース時に逐次自動実行させる
そもそもこの辺りも、世の中のスタンダード的には常識過ぎて何を今更といったところだと思いますが、私が３年間の間に見てきた現場ではそうではありませんでした。
これが今回このポエムを書きたくなったきっかけです。
これまで経験した現場のテストコードに対するスタンス
これまで経験してきた現場のテストコードに対するスタンスは以下のような状況でした。
1
- そもそもテストコードを書くという土台、文化がない。
2
- 単体テストを通すためだけにテストコードを書く（単体テストを通す=カバレッジを100%にする）。
- でもテストコードはソースコード管理ツールにコミットしない。
- CI/CDの仕組みは無いのでテスト自動実行をしない。
- 要は使い捨て。
- WF開発で、単体テストフェーズ以降では使用しない。
- よって、製品コードもテストコードでテストする前提で実装しない。インターフェースなどを使用して依存性を排除したりはしない。
- コード内で
DateTime.Nowが書かれていたりした - Microsoft.Fakes が使えたのでこの辺はMock化してテストした
- コード内で
3
- テストコードを書いて実行させることを単体テストとしてよい。
- ルールにはしていない。テストコードを書くかは開発者の任意。ただし、テストコードはコミットしてはいけない=共有しない。
- テストプロジェクト自体はあるんだけど…なんで？
- Repository は インターフェースで抽象化されているが、Service クラスは Controller の中で new している…なんで？
- 自分の担当分はテストコードを書きました。外部サービス、DBにも依存したままでしたが。
- Controller、Service のメソッドを１つずつテストコードで動作確認するような形で作業を進めました。
4
- テストコードを書いて Git にもコミットして共有する。
- 単体テスト=テストコードの実行。
- だけどCIが無いためローカルで開発者が逐次手動実行するだけ。
大まかに以上のような感じでした。
要するに、前述のテストコードを書いてCI/CDに乗せて自動実行させるところまでできている現場は１つも無かったのです。
|#| テストコードを書く | 共有する | CI/CDで自動実行する |
|---|---|---|---|---|
|1|☓ | NA | NA | SVN、GitHub |
|2|○ | NA | NA | GitLab |
|3|○ | ○ | NA | GitLab |
そもそも前のステップを踏んでいないと、次のステップは実行できないですね。
3のパターンに関しては非常にもったいないなと感じてしました。
MVCのWebアプリケーションだったのですが、各レイヤー感の依存性は排除されていてテストコードも書きやすく、ソースコード管理は GitLab を使用していたので、CI/CDの仕組みに乗せるのはやろうと思えば出来たはず…
そう感じていたのであれば、CI/CD出来るよう提案したら？という声が聞こえてきそうですが、
規模が大きい案件で私のような末端の１開発者が声を上げられるような状況では無かったのです…
お察しください。
自社開発のときはどうしていたか
当時、自社開発企業在籍時はソースコード管理に Microsoft の Team Foundation Server を 利用していました。
利用していくうちにまずは自動ビルド、その次にテストコードを書けば自動ビルドしたあとにテストも自動実行できるっぽいぞ、こりゃすごい！と段階的に気づきながらいまでいうCI/CD環境を構築してました。
※当時はCI/CDという単語は世の中的にもまだ聞いたことがなく、TFSのドキュメントだと「ALM（アプリケーション・ライフサイクル・マネジメント」と書かれていたのを記憶しています。
自動ビルド・テスト自動実行は１日１回実行していました。
自動ビルド導入後は、これまで手動で配置していたテスト、リリース用アプリの配置も自動化して効率化アップ。
レガシーなシステムだったのでテストコードもコアロジックの部分だけなんとか実行できるようにしていただけだったのですが、それでも大規模な回収があるときはデグレを何度も発見してくれて、効果は絶大でした。
この辺り、自社開発だったのでこうしたパイプライン構築なんかは自分の裁量である程度やれていたのは自由度は高くて良かったなあ…と懐かしんでしまいます。
今後
前述の自社開発でのテストコードに関する成功体験があったので、テストコードを書く文化ではない現場、CI/CDの無い現場を見るとモヤモヤしてしまう気持ちが強いのかもしれません。
経験年数的にはそろそろこういった部分も提案できるようなレベルのエンジニアになっていかないとなあ…と感じております。