こんにちは、SWETグループの田熊です。
先日、社内のAndroidアプリエンジニアを対象にユニットテストのハンズオンを行いました。 本記事では、どのようなことを考えながらハンズオンを作成していったのかと、ハンズオンの内容を紹介しようと思います。
なぜハンズオンを開催したのか
これまでのSWETは、メンバーがプロダクトに個別にジョインし、品質保証や生産性向上につながるような取り組みをしてきました。 一方、SWETが関わっていないプロダクトからも「テストがなくてつらい」などの声があがっていたため、自動テストのナレッジをスケールさせていくことも必要だと考えていました。 そこで、自動テストの普及の一貫としてテストハンズオンの実施を検討しました。
社内状況の把握
DeNAはサービスが多岐に渡るため、SWET内で各サービスにどの程度自動テストが普及しているかを把握できておらず、どのようなレベル感のハンズオンを作成すればいいかがわかりませんでした。 まずは現状をより正確に知るために、社内のエンジニアに自動テスト実施状況を確認するアンケートを取りました。
その結果、下記のようなことがわかりました。
- ユニットテストについて
- 約50%がもっと力を入れていきたいと考えている
- 約25%が導入したいと思っているが、できていない
- 作成における課題として多かったもの
- テストが書きにくい設計になっている(50%)
- 工数がとれない(40.9%)
- 費用対効果がわからない(13.6%)
- UIテストやE2Eについて
- 約40%が導入したいと思っているが、できていない
- 作成における課題として多かったもの
- 工数がとれない(36.4%)
- ナレッジがない(36.4%)
- テストが書きにくい設計になっている(31.8%)
この結果をうけて、まずはユニットテストにおける課題の半数を占める「テストが書きにくい設計になっている」について、ハンズオンを通じて何かしらのアプローチができないかと考えました。
なお、初回のターゲットを検討した結果、ネイティブAndroidアプリエンジニアを対象に行うことにしました。理由としては、Androidテスト全書など、ハンズオンの参考になるドキュメントが充実していたからです。
ハンズオンの構成
「テストが書きにくい設計になっている」問題に対してのアプローチを、プロダクトのコードを変更する目的ごとに考えました。
| 変更の目的 | テストが書きにくい設計問題へのアプローチ |
|---|---|
| 新しい機能を追加する | 実装と同時にテストを書くことでテストを書きやすい設計にする |
| 既存の機能を改修する | 少しづつテストを導入しつつテストが書きにくい設計を改善する |
そして、各アプローチを盛り込んだ「テストをはじめよう編」と「テストのないアプリにテストを書こう編」の2つのテーマでハンズオンを作成をすることにしました。 また、各人の時間の都合やパフォーマンス等を鑑み、ハンズオンは2日にわけてそれぞれ2時間で実施とすることにしました。
テストをはじめよう編
テストを始めよう編のアウトラインは下記です。
- 座学
- なぜテストを書くのか
- Androidにおけるテストの説明
- TDDの紹介
- チュートリアル
- TDDチュートリアル（参加者に実際に手をうごかしてもらう）
- 自習（各自お題をTDDで進めてもらう）
アウトラインについて、どうしてこのような構成にしたかを振り返ります。
なぜテストを書くのか
この章では、テストを書くことによるメリットと、書かない場合のリスクについてまとめています。Androidテスト全書の1章とSWET内部で作成した自動テストの効能をまとめたドキュメントを参考にしながら作成しました。
テストを書く習慣をつけるためには、そのメリットについて納得している必要があります。 自動テストのメリットについて昨今のエンジニアであれば一度は聞いたことがあるかもしれません。しかし、普段テストが書きにくいプロダクト開発をしている場合、日常的に自動テストに触れられておらず、そのメリットの認識も曖昧になっているかもしれないと思いました。
よって、なぜテストを書くのか？を改めて確認し、テストを書くモチベーションの向上につなげようという意図があり冒頭に説明をいれました。
Androidにおけるテストの説明
Androidにおけるテストの分類（Unit test、Integration test、UI test）をまとめています。Androidテスト全書の1章を参考にしながら作成しました。
この章はAndroidアプリ開発におけるテストの基礎知識を整理するために追加しました。
TDDの紹介/TDDチュートリアル
TDDは下記の点から題材として最適と思い採用しました。
- テストを書きつつテストが書きにくい設計になるのを防ぐために、TDDのアプローチが有効
- 問題を小さく切り分ける・不安をテストにするといったTDDのエッセンスは、TDDでなくともテストを書いていく上で重要
- 上記のことを学びつつ、テストの書き方を学ぶこともできて一石二鳥
資料
実際にハンズオンで使用した資料をアップしましたので、ご興味がある方はどうぞ！
※外部公開に際し、資料は一部修正を加えております。
Androidテストハンズオン基礎編
TDDチュートリアル
テストのないアプリにテストを書こう
テストのないアプリにテストを書こう編のアウトラインは下記です。
- レガシーコードを改善しよう
- レガシーコード改善に役立つ知識
- テストダブル
- レガシーコード改善テクニック
- テストのないアプリにテストを書こう(参加者に実際に手をうごかしてもらう)
こちらもどうしてこのような構成にしたかを振り返ります。
レガシーコードを改善しよう
この章では、自動テスト実施状況アンケート結果で社内の半数がテストが書きにくい設計を課題としていることを紹介し、地道にテストを導入しつつテストが書きにくい設計を改善しようという提案をしました。
目的は、タイトルの通りレガシーコード改善への動機づけです。テストが書きにくい部分に引きずられてテストを書かずにいると、悪循環になってしまうからです。
レガシーコード改善に役立つ知識
ここでは、テストダブルとレガシーコード改善テクニックの紹介をしました。Androidテスト全書の2章とレガシーコード改善ガイドを参考に作成しました。
テストが書きにくい設計のアプリにテストを書いていくのは、なかなかに難易度が高いタスクです。 テストダブルを使って依存を切り離すテクニックと、レガシーコード改善ガイドにある最低限の修正でテストを書けるようにするテクニックを知っていると、そのタスクの助けになると思いこの章を追加しました。
テストのないアプリにテストを書こう
あえてテストが書きにくい設計で実装したサンプルアプリを題材に、参加者にユニットテストを書いてもらうセクションです。 成果物はPull Requestとして提出してもらい、SWETメンバーがレビューを行う方式にしました。
ここでは、その前の章で説明したテストダブルやレガシーコード改善テクニックを、参加者が実際に使って身につけてもらうことを目的としています。 また、Pull Requestレビューを通じて説明した内容がきちんと伝わっているかと、参加者がお題にどのように取り組んだかを確認できるようにしました。
資料
こちらも実際にハンズオンで使用した資料の一部をアップしましたので、ご興味がある方はどうぞ！
※外部公開に際し、資料は一部修正を加えております。
テストのないアプリにテストを書こう編
ハンズオンの振り返りとその先
ハンズオン実施後に参加者アンケートを取った結果、各ハンズオンの総評は「テストをはじめよう編」が平均4.88、「テストのないアプリにテストを書こう編」 が平均4.78と良いフィードバックをいただくことができました。(5段階評価で5が良い・1が悪い)
ハンズオンの内容の質にこだわったのはもちろん、専用のslackチャンネルを設けて質問をしやすくしたり、講師以外にもTAを3人配置するなどといった運営の工夫も功を奏したのだと思います。
ハンズオンは好評のうちに終えることができましたが、実際にプロダクト状況を改善していくには継続的な取り組みが必要になります。 参加者のテスト導入について相談を受けられるようにし、実プロダクトへの貢献も進めていきたいと考えています。
また、今後もSWETでは社内のエンジニアがテスト技術について学ぶことができるコンテンツの作成を進めていきます。
現在、下記を企画しています。
- ユニットテストハンズオンのiOS編
- モバイルのUIテストハンズオン
- Go言語でTDDを学ぶことができるCodelab
このような取り組みを通じて、社内のエンジニアが自動テストスキルを向上できる仕組みと、社内のエンジニアがいつでもテストについてSWETに相談できるような環境を作っていきます。
最後に、SWETでは一緒に自動テストの普及に取り組んでくれるエンジニアを募集しています。 今回の取り組みに興味を持たれた方は、下記URLからのご連絡をお待ちしております！
募集職種: SWET (Software Engineer in Test) / テスト自動化エンジニア（Android Test）
