こんにちは、Webエンジニアの本間です。
去る2018年5月25日(金)、 株式会社ウエディングパーク の皆さまと合同で勉強会を行いました。 弊社からは以下の2つの内容で発表しました。
- ユニファのWebエンジニアのテスト事情（現状と今後） by 本間
- 新しいスタンダードを作る ユニファのものづくり by 田渕、鶴岡
今回は繰り返しになってしまいますが、自分が発表した1の「ユニファのWebエンジニアのテスト事情（現状と今後）」の内容を紹介しようと思います。
発表概要
ユニファのWebエンジニアのテスト事情ということで、以下のテストに関して現状と今後に向けた内容をまとめています。
- ローカルでの動作確認
- 自動テスト（単体）
- 自動テスト（結合）
- CIでのテストの自動実行
ローカルでの動作確認
現状
- 技術検証、開発者によるテストのどちらでもよく使っている。
- どこまでテストするかは開発者次第。
- 工夫点
- docker, docker-composeを使い、サービス内部で使うマイクロサービスもローカルで立ち上げている。
- 外部のサービスも極力同じもので開発者アカウントを作り、使っている。例：Amazon S3, Sendgrid
課題、今後に向けて
- Docker for Macのパフォーマンス
- ローカルマシンのリソース（CPU、メモリ、ディスク）
- サービスがたくさん増えてきた時のメンテナンス
自動テスト（単体）
現状
- 1クラス1テストファイル
- Model、View、Controller、その他のうち、M、C、その他のみ実施、Vはテストしない。
- Viewは変更頻度が多く、テスト前の準備も大変なため、コストに見合う効果が得られない。
- この次の「結合テスト」とテスト内容がかぶるため、どちらか片方にした方が効率的。
- Controllerのテストでレンダリングまで行うことで、最低限エラーが発生しないことだけは確かめている。
- DB、Redis以外はスタブを使用。
- Rubyはスタブを非常に簡単に扱えるため、テストコードが書きやすい。
- どこまで書くかは開発者次第。
- 個人的には、C0カバレッジ 100%を目指しているが、最近そこまでやる必要あるのか？とも思い始めている。
- 効果
- たまにファインプレーをする。
- テストが通っていると、少しだけ自信を持ってリリースできる。
- メンテのコストは結構かかっている。
課題、今後に向けて
- どこまでテストするかの開発者の認識のずれ。ルールかすべきなのか、今まで通り開発者自身にまかせるべきなのか。
- テストの実行時間の増大。今は4並列で3分ぐらいに収まっているが、今後さらにテストが増えた時どうするか。
自動テスト（結合）
結合テストとは、最終的にサーバーが返す成果物を確認するテストを指しています。 ブラウザ向けの画面であればJavaScript含む画面の内容が、APIサーバーであればレスポンスJSONの中身などが想定通りかチェックします。
現状
- APIでは最終的なJSONの内容を含めたテストがある程度できている。
- 一方、画面に関するテストはエンジニアレベルではできていない。
- Rails 5.1からはSeleniumと連携したテストがすごく簡単にかけるようになった（発表中、デモしました）。
- 具体的には、Chromeとchromedriverがインストールされていれば、特に設定をしなくても（= rails newしただけの状態で）SeleniumからChromeを使ったテストが実行可能。
- Headless Chromeへの対応もしている。ローカルで開発しながら、裏でテストを動かすとかもできそう。
課題、今後に向けて
- 最終的なアウトプットを確認できるので効果が高いはず。
- 積極的に書いていきたい。
- CIで動かせると最高。
CIでのテストの自動実行
現状
- CIサービスを利用
- 実行タイミング
- git push
- PR merge
- 実行内容
- 自動テスト（単体）
- 静的解析
- (一部)QAチームの自動ユーザーシナリオテスト
- 結果
- Slackに通知
- PR上にも結果を表示
課題、今後に向けて
- 使うCIサービスの統一
スライド
発表したスライドは以下（インターネットに公開するにあたり、一部内容を変更しています）
質問と回答
当日いただいた質問と、改めて考えた結果の回答を記載します（当日はテンパっててまともに回答できなかった気がします...）。
- テストコードを書く文化作りでやっていることはあるか？
-
- 特にないが、みんな自然と書いている。
- 幸い、自分がJoinした時には一通りテストコードがそろっていた。
- Ruby on Railsでは、フレームワーク内に自動テストの機能が備わっており、チュートリアルからテストを書くので、その影響も大きいと思う。
- 個人的には、新卒入社した会社で当たり前のように書いていたので、書くのが当たり前だと思っていた。
- 参考にならなくて申し訳ないです。現在、テストコードを書く文化がないのであれば、書ける人が少しずつ広げて行くしかないと思う。リリース時やバージョンアップ時など、自動で回帰テストできると非常に楽なので、その便利さに気づいた人が少しずつ増えていくはず。
- 自動テストを導入することによりバグ発生率はどの程度減るのか？
-
- テストなしの状態と比較できないのでわからない。
- QAチームからは、一般的な平均からバグの数は少なめと聞いている。
- テストコードで見つかるバグは数は少ないが、QAで気づかないものが多い（予期せぬ箇所に影響が出ているケース）ので、効果はあると思う。
- プログラミング言語やフレームワークのバージョンアップなど、システム全体に影響がある修正のケースでは大きな効果が見込めると思う。
- テスト駆動開発はやっているか？
-
- ほとんどやれていない。明らかな不具合の時だけ先にテスト書いて失敗させてから、修正している。
- やはり、先に実装して動かしたい気持ちが出てしまう。
- 先にテストを書いた方が良い場面、実装後に書いた方がよい場面があると思う。ここは、テスト駆動をよく使っている経験者の方に話を聞いてみたい。
合同勉強会の感想、反省など
- 緊張してしまい、話す速度が早かった。もう少しスライドの量減らした方がよかった。
- 先方のリプレイス案件の発表は、すごく共感できた。
- 会社の文化の違いが様々なところに出てて、面白かった。
- ウエディングパークの皆さん、若くて元気ある!! オジサンも負けずに頑張ろうと思った。
以上です。
