ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

ユニファのWebエンジニアのテスト事情

こんにちは、Webエンジニアの本間です。

去る2018年5月25日(金)、 株式会社ウエディングパーク の皆さまと合同で勉強会を行いました。 弊社からは以下の2つの内容で発表しました。

  1. ユニファのWebエンジニアのテスト事情(現状と今後) by 本間
  2. 新しいスタンダードを作る ユニファのものづくり by 田渕、鶴岡

今回は繰り返しになってしまいますが、自分が発表した1の「ユニファのWebエンジニアのテスト事情(現状と今後)」の内容を紹介しようと思います。

f:id:ryu39:20180529175142j:plain
発表前で緊張している様子

発表概要

ユニファの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で気づかないものが多い(予期せぬ箇所に影響が出ているケース)ので、効果はあると思う。
  • プログラミング言語やフレームワークのバージョンアップなど、システム全体に影響がある修正のケースでは大きな効果が見込めると思う。
テスト駆動開発はやっているか?
  • ほとんどやれていない。明らかな不具合の時だけ先にテスト書いて失敗させてから、修正している。
  • やはり、先に実装して動かしたい気持ちが出てしまう。
  • 先にテストを書いた方が良い場面、実装後に書いた方がよい場面があると思う。ここは、テスト駆動をよく使っている経験者の方に話を聞いてみたい。

合同勉強会の感想、反省など

  • 緊張してしまい、話す速度が早かった。もう少しスライドの量減らした方がよかった。
  • 先方のリプレイス案件の発表は、すごく共感できた。
  • 会社の文化の違いが様々なところに出てて、面白かった。
  • ウエディングパークの皆さん、若くて元気ある!! オジサンも負けずに頑張ろうと思った。

以上です。