以前YUMEMI.swiftに登壇した際に、YUMEMI.swiftなのにSwiftに関する話は全くなく、自動化の話をしたので勝手にYUMEMI.自動化 #1と名付けたら、ゆめみの方から「是非やりましょう」となり一緒に開催することになりました。

今回僕が発表したのはMagicPodといい感じに付き合っていくという内容です。
資料はこちら。

発表内容

MagicPodについて

GUIでぽちぽちするだけでモバイルアプリやウェブのE2EテストができるSaaSです。
弊社もMagicPodのユーザーとしてインタビューしていただいたのでよければ見てください。

note社アプリチームでのMagicPodの利用状況ですが、

• プラン: スタンダードプラン（プロジェクト5つ）

• 合計のテストケース数が60件

• 一括テストは毎朝7時に定期実行、masterブランチにマージするタイミング

です。
そんな感じで運用している中で抱えていた問題が2つあったので紹介します。
一つはテスト結果の通知がメールでしかこなかったという点と、同時並列数が2つまでしか対応していないという問題です。
どちらも大きな問題ではないのですが、ここではなんとかして解決しようと工夫したことを紹介します。

テストの結果の通知がメールでしかこなかった

メールの通知はメールを開かないと詳細が見れないので、どのテストが失敗したのか分かりづらかったという問題がありました。
もはや業務上の優先度としては圧倒的にSlackの方が高く、メールは二の次になっている実情もあります。
また、MagicPodのテスト結果のメールがなぜか英語と日本語のいずれかが届くようになっており、Zapierなどを経由してSlackに通知するというのも難しいという問題もありました。
そこでこれまでは定期的にZapierからMagicPod APIを叩いて最後の結果を通知するようにしていました。
MagicPod APIのドキュメントはこちらです。

定期実行にはZapierを利用しています。

毎日定時になったらAPIを叩いて、結果をゴニョゴニョしてSlackに送信するだけです。

APIを叩くのはシンプルで、URLとヘッダーだけ指定しています。

結果はこんな感じでゴニョゴニョしています。
ここは環境に合わせて修正すればいいと思います。
注意点としては引数の結果がカンマ区切りの文字列で渡されるということですね。

結果はこんな感じで通知されるようになっています。
これを作ってみたことで、結果の成功か失敗かが可視化されるようになり、失敗している場合には、「修正しなければ」と思えるようになりました。
とはいえリアルタイムで通知されるとより便利だなぁと思っていました。
そんなところに朗報が飛び込んできました。

MagicPodは課題をGitHub Issuesで公開しているのですが、そこで「Slackにテスト結果を通知して欲しい」というissueがCloseされ、対応が完了したことが報告されました。
Slack通知への設定方法ですが、

• （設定がなければ）テスト一括実行に設定を追加

• 共通設定を開く

• テスト結果をSlack通知: するに変更

  • 通知用webフックを追加（適当な名前を付与）

  • Slack連携を選択して通知先のチャンネルを設定

  • 完了したら通知用webフックに作成したものを選択

で完了です。

これにより、テストが成功した場合には成功したことがわかり、失敗した場合にはどのテストが失敗したのか明確になりました。

MagicPod APIでの設定方法

これらの設定はMagicPod APIからも可能です。

方法はcross-batch-run APIにslack_notification用のオブジェクトを設定します。

magicpod-api-clientでの設定方法

magicpod-api-clientも同様に、slack_notificationオブジェクトを設定することで対応できます。

SlackNotificationNameは設定したものに適宜書き換えてください。

同時並列数が2つまでしか対応していない問題

これはプラン次第ではあるのですが、スタンダードプランだと現状2並列までしか対応していません。
API経由でテスト一括実行を3つ目以降を追加しようとすると、弾かれてエラーになってしまいます。（CI的に失敗したステータスになります）
これも大きな問題というわけではないのですが、CIの失敗を目にするのは精神衛生的にはよくないですね。
また、開発人数が増えればこちらのエラーが発生しやすくなってしまいます。これは現状masterブランチへのマージ時に一括テストを実行しているためです。
特にリリース前や細かいバグの修正を頻繁に行ったり、溜まったPRをまとめてレビューしたりするとすぐに発生してしまいます。
MagicPodに関するエラーが発生するのが当たり前になってしまうと、メンテナンスされなくなってしまうという問題が発生しかねません。
そこで

• SlackのSlash commandで一括テストの実行状況を取得してみるということ

• 実行中のテスト件数を取得して2件実行している場合にはテストの登録をしない

ということを試しました。

SlackのSlash commandで一括テストの実行状況を取得

SlackのSlash commandで一括テストの実行状況を取得するZapierのワークフローがこちらです。
最初のトリガー以外は先ほど説明した 定期的にZapierからMagicPod APIを叩いて前回の結果を通知してみた とほとんど同じですので詳細の紹介は割愛します。

ZapierウェブフックのURLをSlash commandに設定します。

実行した結果はこんな感じです。
これを作成した際の意図としては事前に状況を確認して、問題なければPRをmasterにマージするみたいな運用を考えたのですが、現実的じゃないなと思いました。
そこで試してみたのが次の案です。

実行中のテスト件数を取得して2件実行されている場合にはテストしない

実行中のテスト件数を取得して一括テストが2件実行されている場合にはテストしないようにしました。
これによりこれまでは一括テストが2件実行されている場合にはCIがエラーで落ちていたのですが、テストを実行せずに終了するだけになりました。
これでアプリチームの精神衛生も保たれるようになるはずです。

#!/bin/sh
brew install jq
MAGICPOD_API_URL="https://magic-pod.com/api/v1.0/${MAGICPOD_ORGANIZATION}/${MAGICPOD_PROJECT}/batch-runs/"
MAGICPOD_API_RESPONSE=`curl -H "Authorization: Token ${MAGICPOD_API_TOKEN}" ${MAGICPOD_API_URL}`
NUMBER_OF_RUNNING=`echo $MAGICPOD_API_RESPONSE | jq '.batch_runs | map(select(.status == "running")) | length'`
MAX_RUNNABLE=2
if [ $NUMBER_OF_RUNNING -ge $MAX_RUNNABLE ]; then
  echo "Too many running..."
  exit 0
fi
...

まとめ

MagicPodはとても便利でありがたいサービスなのですが、完全ではありません。特にテスト以外の部分で足りないものは自分たちで補っていくのがいいと思います。
APIなど公開されているものは色々活用していきたいですね。
また、定期的に発生する問題は自動化のチャンスです。
細かいことでも積み重なると問題が定常化してしまい悪循環ですね。
よく言われることですが、毎回コケるテストは段々メンテナンスされなくされなくなってしまうという問題があります。
手遅れになる前に凪を手に入れましょう。

P.S.

note社では品質に対して一緒に向上してくれる方を募集中です。
全社的な品質向上に一緒に取り組んでくれる方がいましたら是非お声がけください。