ロコガイド テックブログ

「地域のくらしを、かしこく、たのしく」する、株式会社ロコガイドの技術部ブログです。主にトクバイ・ロコナビのサービス開発について発信しています。

「地域のくらしを、かしこく、たのしく」する、株式会社ロコガイドの技術部ブログです。
主にトクバイ・ロコナビのサービス開発について発信しています。

Instrumentationテスト 最初の小さな一歩

2020年1月入社のiaiaです。

Androidアプリエンジニアとしてトクバイアプリをメインに開発していますが、 テスト環境を改善していくことで、開発をしやすい環境にしていきたいと考えています。 テストがしやすい/テストコードが充実している/テストコードを書きやすい環境であれば、 うっかり忘れやミスなどを早期に発見でき、改善のサイクルを高速に回せるはずと信じているからです。

そのための最初の一歩としてInstrumentation Testやっていこうぜ!っていう話をします。

やりたくない仕事

入社してすぐにやりたくない仕事にぶち当たりました。

f:id:iaiaie:20200413194214p:plain

モンキータイムです。

モンキータイムとは

モンキーテストとは

トクバイアプリの開発は2週間のスクラムで、 最終日(2週目の金曜)の夕方に、そのスプリント内で実装したもののリリースを行うか判断を行います。 その最終判断の直前に、モバイルアプリエンジニアによる人力モンキーテストを行っています。

アプリの状態を人間の手と目で確認することは重要で、

  • 想定外の挙動をして不具合を起こしていないか
  • ユーザの体験が悪くなっていないか

などを、実際のユーザに届ける前に、事前に見つけることができます。 しかし問題もあります。

  • 複数の状態の組み合わせで大量の状態がある
  • 面倒なところをチェックしたがらない
  • そもそも面倒
  • 約30分 * Androidアプリエンジニア2人 * 2回/月 = 1440分/年 = 3人日がモンキータイムに奪われる
  • ヒトは本当のモンキーになれない

モンキーテストの回避策を考える

メリットは重々承知だが、(主に面倒なので)モンキーテストをやりたくない! 人間としてやりたくないことをやらないようにするのはエンジニアの得意なところだと思います。 回避策がいくつか思い浮かびます。

やらない

  • チェックをせずにユーザにそのまま届ける
  • モンキーテストで拾えていたバグなどもそのまま届いてしまう
  • 品質という点で悪くなってしまうので却下

やってないのにやったと報告する

  • 「やらない」より悪い
  • 社内からの信用を失ってしまうので却下

思考停止して最小努力のモンキーテスト

  • 結局やっていることには変わりがない
  • 通常のモンキーよりチェック項目が減る可能性 => 品質が落ちる可能性

エンジニア以外の人にやってもらう

  • エンジニアの想定外を起こしてくれる
  • でもヒトがやっていることに変わりがない

ロボットにやってもらう

  • 自分はやらなくて済む
  • 他のヒトもやらなくて済む
  • エンジニアの想定外を起こしてくれる
  • 完璧では?

ロボットにテストやってもらいましょう

私のように「モンキーテストなんてやりたくない」とブツクサ文句を言わないロボットに、テストを継続的に行ってもらいましょう。

AndroidではUnitテスト(プログラム関数などを対象)とInstrumentationテスト(実際のアプリ画面を対象)で自動テストを実現します。

今回はモンキーテストのような画面でのテストを無くしたいので、画面でのテストを自動で出来るInstrumentationテストを、まずは簡単なところから追加すると良さそうです。

f:id:iaiaie:20200413194252p:plain

Robo Test

今すぐ全部の画面のテストを書けるかというと、たくさんありすぎて時間がかかる。その間にも画面は変化していくし、新たなバグも出てくる。 ざっくりとで良いのでUIテストを実行していきたいですよね。

Firebase Test LabのRobo Testを実行してみました。

f:id:iaiaie:20200413194337p:plain

継続的に実行していく

  • Instrumentationテストはローカルで実行するのかなり時間かかる
    • でも最低1日1回程度で良いのでやってほしい
    • ちょっとした文言変更でもクラッシュするはず
      • 修正 => ビルド => 実行 => 確認 => 修正 のサイクルをすると開発が遅くなる可能性
  • Robo Testも1日1回は実行したい
  • Bitriseで夜中に定期実行(月~金の0:10に開始)するようにしました

まとめ

  • トクバイアプリに今まで無かったInstrumentationテストを追加できた
  • 自動UIテストを継続的に実行できるようになった
  • でもモンキータイム無くなってないよね...
    • Robo Testでチェックしてくれない箇所が多い...
    • やっぱり人間の目と手で確認重要
  • Robo Testがやってくれるメモ機能やお問い合わせあたりはやらなくて良いかも!
  • 開発の生産性向上できた?
    • いや別に...
  • Instrumentationテスト全然増えない問題
    • 書くの大変...

現段階で目に見える価値が作れたかというと微妙です。 ただこの最初の一歩目を踏み抜いておいたので、後々本格的にやろうとするときに、2歩目を踏み出しやすいはず!と思っています。 具体的には、CI環境整備するとか、テスティングフレームワークを入れるとか、テストクラス作っておくとか、準備が多くてつまづきやすい。これだと本当にやりたいことに対するモチベーションが薄れてしまう。 後はテスト書くだけですよ、という状況を作りだすことでテストへのモチベーションを維持する => テストが豊富な状態になる => 品質が保証されやすくなる => ガンガン開発しやすくなる!と信じています。

今回の話は小さな一歩ですが、2歩目3歩目を踏み出しています(ActivityのテストだけでなくFragmentのテストも追加した)。

また別の最初の小さな一歩として、iOSアプリの起票ライブラリのHuruhuru techblog.locoguide.co.jp をandroidアプリ用に作って導入しました( Furufuru )。自動テストだけでなく手動テストの環境を構築していくことも重要だと思っています。

最初の小さな一歩でも踏み出してくれる方、さらに2歩目3歩目を一緒に歩んでくれる仲間を募集しています!

www.wantedly.com