発表・イベントリポートこんにちは。SWETグループの外山(@sumio_tym)です。先日、社内のAndroidエンジニア向けにUIテストのハンズオンを開催しました。本記事では、ハンズオンを開催するに至った経緯と、その内容を紹介します。UIテストハンズオン開催の経緯SWETでは、社内のエンジニアに自動テストのナレッジを普及させるための取り組みを継続しています。2019年4月に開催したAndroidユニットテストのハンズオンもその一環でした。当時のAndroidユニットテストのハンズオン参加者を対象としたアンケートで「次に開催してほしいハンズオン」について尋ねていました。UIテスト1のハンズオンを開催することにしました。ところで、Androidの公式ドキュメントで紹介されているテストピラミッドによると、UIテストの推奨割合はテスト全体の10%程度とされています。本記事の読者の中には、10%のUIテストのためにハンズオンを開催する価値があるのか疑問に思う方もいらっしゃるかも知れません。UIテストの特徴や使い方の理解は避けて通れないと考えています。それらが理解できてはじめて、テストをどのアプローチで自動化するか判断できるようになるからです。手動でテストした方が良いのではないか?このような判断ができるようになることも念頭に置いて、UIテストハンズオンのカリキュラムを検討しました。UIテストハンズオンの用途にはぴったりです。いえ、出版されてからの1年間でAndroidのテストを取り巻く状況も変化してきています。Androidのテストを取り巻く最新トレンドを踏まえて、次の内容も盛り込むことにしました。UIテストのナレッジを常にアップデートしてきました。そのため、より現在のAndroid開発に適したものとなるよう、柔軟にカリキュラムをアレンジできました。「Androidテスト全書」のUIテスト部分は4章から6章で構成されていますが、今回は次のような理由により4・5章のみをベースにしています。ユニットテスト・UIテストのどちらで実装するかを含めた判断をするためには、UIテストの特徴や導入前の検討事項がまとまっている4章「UIテスト(概要編)」の理解が不可欠であるAndroidエンジニアがテストを書くケースを考えると、Appium(6章)よりもEspresso(5章)の方が取り組みやすいこれらの内容を「基礎編」と「応用編」に分け、それぞれ2時間(合計4時間)で実施することにしました。「基礎編」のカリキュラム基礎編のカリキュラムは次の通りで、外山と田熊(@fgfgtkm)が作成しました。前半の1時間が座学で、後半の1時間がハンズオンです。座学はほぼAndroidテスト全書の4章に沿った内容です。基礎編では思い切って、EspressoのAPI説明を全て割愛することにしました。Recorderを使えば簡単に実現できるからです。Objectデザインパターンを適用できること」であると考えました。その考えを元に、ハンズオン部分はEspressoのAPIを知らなくても進められるような構成にしています。UIテスト未経験のAndroidエンジニアでも保守性の高いUIテストの書き方を習得できる内容になりました。Codelab形式で作成しました。Codelab形式で作成することにより、今回参加できなかった方も独学でハンズオンを進められるようにしました。「応用編」のカリキュラム応用編のカリキュラムは次の通りで、田熊と鈴木穂高(@hoddy3190)が作成しました。Codelab形式で作成しました。2019アプリのCoroutinePlugin.kt応用編では、受講者が次の2点を習得できるようにカリキュラムを検討しました。ActivityやFragment単体をテストできる仕組みです。FragmentScenarioはFragment単体を起動してテストできる点が画期的です。ともカリキュラムに組み込みたいと考えました。ほとんどのアプリで必要になる次の2点を重点的に学ぶ内容にしました。実践的な内容になっています。UIテスト実装時に直面しがちな問題への対処法を学べるカリキュラムを実現できました。「応用編」が平均4.71と良いフィードバックをいただくことができました(5段階評価で5が良い・1が悪い)。参加者を中心に各プロジェクトが自律的に自動テストを書くようになって、はじめてこの取り組みは成功したと言えます。SWETでは、これからも各プロジェクトが自律的にテストを書けるようになるための取り組みを継続していきます。最後に、SWETでは一緒に自動テストの普及に取り組んでくれるエンジニアを募集しています。Test)ここではアプリのUIを操作が発生するテスト全般のことを指しています。UI操作を伴うものであればend-to-endテストに限りません。発表・イベントリポートSWETの加瀬(@Kesin11)です。2019にて登壇する機会を頂き、「iOSアプリのリジェクトリスクを早期に発見するための取り組み」という発表をしました。当日は時間の都合上、紹介したツール(以降、AppChecker)がipaをどのように解析し、どのようにチェックを行っているかというロジックの要点だけの紹介しかできず、コードを示した解説まではできませんでした。AppCheckerは社内の要件やフローに特化した作りとなっているために、残念ながら今のところOSSにする予定はありません。自分たちと同様のチェッカーを実装したい方が参考にできるように、どのような実装しているのか簡単なサンプルコードで紹介したいと思います。SDKのバージョンのチェックを行っています。YOUR_APP.ipa上記のコードは非常に簡易的なクラス設計となっていますが、実際のAppCheckerは多くのチェック項目を扱え、今後の拡張性を考慮した重厚なクラス設計となっています。実際のAppCheckerは、このコア部分を呼び出すラッパーとしてThorでコマンドラインから呼び出せるようにした"スタンドアローン版"と、Fastlaneから呼び出せるようにした"Fastlaneプラグイン版"の2種類を提供しています。いうコマンドでひな形となるファイル一式を生成できるため、意外に予想していたよりも簡単でした。何らかのRubyの便利スクリプトをお持ちであれば、こちらのドキュメントを参考にしてFastlaneプラグインにしてみるのも良いかもしれません。テスト、CI/CDAppCheckerは社内の多くのチームのビルドパイプラインに組み込んでもらうことになります。そのため社内ツールといえども非常に高い品質が求められ、それぞれのチェック処理は必ずユニットテストを書きながら開発しました。pull-requestによって走るCIではそれらのユニットテストに加えて、Bitriseで実際にサンプルアプリからビルドしたipaに対してAppCheckerを実行してエラーが発生しないことを確認するテストも実行しています。この確認をする理由は、AppCheckerがxcrunなどXcodeと関係する外部ツールを内部的に使用しているためです。Xcodeのバージョンが上がった際にそれらのツールが期待どおりに動作しなくなる可能性が存在するため、最新のXcode環境を使用できるBitriseを活用して常に最新のXcodeの環境でエラーなく動作することを確認しながら開発しています。#2にて発表していました。そのときのスライドはこちらになります。Storeのガイドラインは今後もアップデートされ続けていきます。こちらのAppleのデベロッパー向けニュースは、朝刊を読むのと同じように毎日チェックしましょう。https://developer.apple.com/news/rss/news.rss日本語版は本家の英語よりも数日遅れて発信されるため、できれば英語版のRSSをチームのSlackに流してチーム全員でチェックするのが良いでしょう。Guidelinesのurlはこちらです。https://developer.apple.com/jp/app-store/review/guidelines/現在のところ1ページに全て収まっています。現行のガイドライン本文を保存しておき、次回の更新時にdiffを取ることでどの部分が更新されたのかハッキリと分かるでしょう。終わりにiOSDCで発表したAppCheckerについて補足をさせて頂きました。当初、SWETで開発がはじまったAppCheckerですが、現在はQAグループ内の自動化を推進しているチームに開発・運用を移管し、アプリがよりリリースしやすい形となるような体制にしています。SWETではテスト自動化の普及に加え、こうした全社的にコストを下げる仕組みの提案・開発なども行っています。iOSに限らず、複数の技術領域でエンジニアを募集しています。ご興味を持たれた方はぜひご応募ください。2019でリジェクトリスクを低減する取り組みについて発表しましたTweet2019-07-19SWETの2名が執筆した「iOSアプリ開発自動テストの教科書」が発売されましたiOSこんにちは、SWETの細沼(@tobi462)です。私と同じくSWETの平田(@tarappo)の2名で共著しています。単行本(ソフトカバー)この商品を含むブログを見る発売を記念して、本書が生まれた背景や各章の見どころについて、かんたんに紹介させていただきます。企画の立ち上がり本書の企画が持ち上がったのは2017年6月と、今からおよそ2年前のことになります。それに参加された技術評論社の方から「iOSテスト本を執筆しませんか?」という提案を受けたのがきっかけでした。テストやCI/CD・デバッグテクニックといった少し進んだテーマを扱った書籍はありませんでした。Nightでは、テストについてのナレッジ共有を主目的としており、それは一定数の成果を収めていたと思います。断片的な情報にとどまっており、体系化されたナレッジとしては整っていないという課題感を持ち続けていました。それが書籍という形で体系化され世の多くのエンジニアに知ってもらえることには十分な価値があると考え、本書の執筆を決めました。本書は、5パートで構成されています。第1部:自動テストについて第2部:単体テスト第3部:UIテスト第4部:CI/CD第5部:デバッギング執筆の開始当初は、テストにまつわるTIPSをまとめた、いわゆる「TIPS本」のようなものを考えていました。一から体系的に学べるような構成に大幅に変更となった経緯があります。結果としてよりよい書籍に仕上がったと感じています。本書籍では、自動テストについて初歩から体系的に学べるような内容となっており、主に以下のような読者を対象としています。「中級者」以上の方でも何かしら得られる内容に仕上がっているかと思います。実際に購入すべきかの判断については、ぜひ書店などで立ち読みして判断いただければ幸いです!各パートの見どころここからは各パートの見どころについて紹介していきます。第1部:自動テストについて第1部では、自動テストを実装・運用するにあたり知っておいたほうが良いことについて記載しています。1章:自動テストをはじめる前に2章:自動テストにおける落とし穴を避ける1章では、自動テストをはじめる前に知っておくと良い「自動テストを実装する目的」や「自動テストを実装する際に意識するべきこと」などについて説明をしています。2章では「テストケース名の話」から、「実行時間をどうするかといった話」といった自動テストを利用していく上で落とし穴になりえるであろうことについて説明をしています。事前にこれらのことを知っておくことで、より自動テストを活用できると思います。第2部:単体テスト第2部では、XCTestの基本から実践的なテクニック、およびOSS活用について記載しています。3章:XCTestを利用した単体テスト4章:単体テストに役立つOSSを活用する3章のXCTestでは基本的な利用方法から始まり、標準のAPIをほぼ網羅するように解説しています。その上で、独自アサーションの書き方や非同期APIのテストについて、初心者でもわかりやすいように丁寧な説明を心がけました。テストが書きづらい場合の対処など、より実践的なケースについても軽く触れています。4章では、以下の4つのOSSについて解説を行っています。Testing)考え方が異なるOSSの解説を通じて、様々なテストテクニックを学んでもらえることを狙いとしました。これらの軸を知ることで、流行などに振り回されないOSS選定ができるようになれば幸いです。第3部:UIテスト第3部では、XCUITestを利用したUIテストについて記載しています。5章:XCTestを利用したUIテストの基本6章:XCUITestのAPIを理解する7章:UIテストの一歩進んだテクニックXCUITestを用いたUIテストの基本から、提供されているAPIの使い方についてある程度網羅的に解説しています。実践的なテストコードの書き方についても軽く触れています。これらの章を通じて、XCUITestでどのようなことができるのか分かって貰えればと思います。第4部:CI/CD第4部では、CI/CDについて記載しています。本パートでは、CI/CDとはという説明にはじまり、実際のサービスの利用例を中心に紹介しています。デバイスファームについてはまだ利用されてない方も多いと思います。本パートの情報により、実際に触ってみる一助になれば幸いです。第5部:デバッギング第5部では、iOSアプリ開発における様々なデバッグテクニックを紹介しています。12章:デバッグのテクニックデバッグツールは使いこなせば強力なものですが、なかなか学ぶ機会がありません。本書ではブレークポイントやLLDB、Xcodeに用意されたデバッグ機能などについて、初心者でも分かりやすいような解説を心がけました。明日から使えるテクニックばかりなので、日々の生産性向上につながればとても幸いです。執筆することになったきっかけや見どころについて解説させていただきました。今後、社内でiOSのテストに関するハンズオンなどを開催していく予定ですが、それの教材や題材作成の元ネタとして、我々自身もこの書籍を活用していく予定です!iOSアプリ開発は、Androidアプリ開発と違い、公式ドキュメント・サンプルコードが少なく苦労することも多いと思います。自動テストについてのドキュメントは少なく、簡素なAPIドキュメントをもとに試行錯誤する現状も多いはずです。モデル検査こんにちは、SWETの鈴木穂高(@hoddy3190)です。私は、こちらの記事で紹介されているようなAndroidテストの教育活動をする傍ら、形式手法という技術の可能性を模索しています。今回は、形式手法についての簡単な説明や、調べていくにつれてわかってきた実用可能性等をご紹介できればと思います。動機まず、なぜ私が形式手法について調べようと思ったのかをご説明します。SWETに所属する前、私は、別の部署で4年ほどゲーム開発に携わっていました。そこでよく課題に感じていたのは、日本語で書かれる仕様の不備(考慮漏れ、記載漏れ、矛盾など)により、大きな手戻りにつながることが多いということでした。開発プロセス上でそのような問題が発生すると、当然再発防止策MTGが開かれます。考慮漏れを防ぐためのチェックリストなどがよく再発防止策として施行されます。プロダクト特有の属人性の高い知識が求められるレビューやチェックリストの目視チェックは、段々と運用の綻びが出てきます。技術的なアプローチでこれらを解決できないかを考えるようになりました。そこで出会ったのが、形式手法という技術です。形式手法とは形式手法とは、仕様を明確に記述したり、記述された設計の性質を機械的に検証する手法の総称です。実は形式手法自体の研究は1970年ごろから始まっており、その歴史は深いです。形式手法を適用して品質向上につながったという事例は、欧米を中心に多く報告されています。導入事例としてどのようなものがあるのかは、形式手法の実践ポータルがよくまとまっていると思います。航空宇宙や鉄道など、高い信頼性が必要とされる分野での事例が多いです。公開されている事例は多くありません。私はまず、形式仕様記述とモデル検査について、調べてみたり、実際に触ってみたりして、前述した仕様書の問題への解決に活用できそうかを検討しました。モデル検査ともに、開発へ適用する際のコストの高さや、仕様書問題への解決策として本当に効果的かという点に懸念が出ました。モデル検査においては、設計や実装の考慮漏れを防げる可能性がありそうだということがわかってきました。モデル検査についてさらに詳しく調べてみることにしました。別のアプローチの解決策を模索していますが、今回は触れません。モデル検査についてモデル検査とは、システムを有限個の状態を持つモデルで表現し、モデルが取りうるすべての状態を機械的かつ網羅的に検査することで、システムが仕様を満たすことを確認する手法です。bがあったとし、「aとbの積が常に9以下である」が成り立つのかを確認したいとしましょう。モデル検査の手順としては、次のようになります。検査したいもの(仕様書、ソースコードなど)から専用のモデリング言語でモデルを作成する検査対象が満たすべき性質から検査式を作成するモデル検査ツールにかけるモデルを作成すると下のようになります。検査式は、assertから始まる部分になります。モデル検査のモデルを書くための言語にはいくつか種類があるのですが、ここではPromelaという言語で記述しています。上で定義しているChooseがインライン展開され、aには1から3のいずれかの値が代入される。9)}モデル検査ツールにはSpinというツールを使います。コマンドラインで検査にかけることができます。9を満たすことを確認します。モデルに一切そういうロジックを書かずに、このような網羅的な探索ができるのも、モデル検査の良いところです。9)に置き換えるとどうなるでしょう。9を満たさなかったaとbのすべての組を反例として示してくれます。3)のときに、検査式を満たさなかったことがわかります。このように、モデル検査は、自動的に網羅的な検査をしてくれます。そのため、並列システムの不整合のような再現させづらいタイミングで発生する不具合や、場合分け不足など設計の考慮不足が起因の不具合などを効果的に見つけてくれます。品質の高いソフトウェアを開発するための有効な手段の1つになるだろうと考えています。モデル作成の難易度が高いというデメリットもあります。実際のシステムをうまく抽象化してモデルを作成するスキルも求められます。Night#6で発表した、「形式手法について調べてみた」に掲載しております。お時間があれば是非ご覧になってください。PoCづくりモデル検査の仕組みがわかったところで、プロダクトに適用できるのかどうかを確かめるために、いくつかの簡単なPoCを作ってみることにしました。Conceptの略で、ここではモデル検査の実用性を確かめるために、簡単なデモを作ることを指しています。PoCの題材決めに際しては、プロダクトに適用する可能性も加味し、プロダクト開発でよく起きる設計・実装上の問題にフォーカスすることを心がけました。そこで、テーマとして挙げたのは、MySQLです。MySQLは、トランザクション分離レベルごとの挙動の把握が難しく、障害につながることがよくあると思います。今回はMySQLにおけるdeadlockの検知をするモデルのご紹介をしたいと思います。複数のプロセスから、CRUDのクエリをランダムにそのモデルに投げ、異常が起きるかどうかを検査します。}}では、モデル検査ツールにかけてみましょう。stateというメッセージが出力されます。これは、網羅的な検査をしていく中で、実行可能な文がなくなったことを意味します。created出力された結果を見ると、53行目のinsertの中で処理が先に進めなくなったことがわかります。updateで共有ロックをとったものの、お互いinsertに進行ができなくなったようです。これがMySQLでいうところのdeadlockに相当します。実際の運用では、このトランザクション内の処理を、プロダクトコード内の処理にあわせてCRUDの組み合わせや順番を変更することを想定しています。先に書いたとおり、モデル検査には「モデル作成の難易度が高い」というハードルがあります。低コストでモデル検査を行える可能性があると考えています。設計確認としてのモデル検査UIのようなイベント駆動での非同期処理の設計確認にもモデル検査が使えます。簡略化して書きますが、APIから取得した要素をリストビューに追加し、追加要素の中心となる位置までスクロールするという処理を実装した際、以下のような設計ミスに気づいた事例がありました。ように考慮漏れが起きやすい処理の設計の検証にもモデル検査が有効です。7)}モデル検査にかけると、反例として、「要素数は9だが、スクロール位置は3」が経路と合わせて出力されます。created今回の実装で問題だったのは、別々のストリームで非同期処理をおこなっていたことによるものでした。中心位置取得のリクエストが投げられる追加するリスト要素を取得するリクエストが投げられる中心位置取得のリクエストの結果が返ってくる追加するリスト要素を取得するリクエストの結果が返ってくるとなっており、意図していた挙動とは異なることがわかります。別々のストリームで非同期を走らせると、処理順番は常に同じにならないというのは、非同期処理を扱う上で基本的な話ではあります。設計の欠陥に実装した後気づくのと、実装の前に気づくのとでは手戻りのインパクトが異なります。注意の勘所がわかっていないと気づくのは難しいです。自分が考えている設計が本当にこれでよいのか、考慮漏れはなさそうかを確認するためにも有効だろう思いました。今後の展望いくつかのPoC作りを通して、モデリング言語で表現できる範囲がわかってきました。これからは、実際のプロダクトコードにモデル検査を適用できる部分を探してみたいと思います。その方向でさらなる可能性を見極めていきたいと思います。さいごにこのようにSWETでは、少しずつではありますが、形式手法の可能性について研究をしています。経過をかなり省いて書いてしまった部分もありますが、なにか疑問がございましたら、@hoddy3190までお尋ねくださいませ。本記事の続報についてはbuildersconでお話できればと思っています。会場にお越しください!形式手法の研究は私含め2人のメンバーで行っております。2人とも半年ほど前に形式手法をはじめたばかりです。(ゲームアーキテクチャ)また、その他のチームへのご応募お待ちしております。JUnit5でUIテストを書こうAndroidこんにちは。SWETチームの@zhailujiaです。Junit5を使ったUIテストの書き方を紹介して行きたいと思います。5テストをまだ公式対応していません。1.0.0Libraryをリリースしました。これによりAndroidXのActivityScenarioなどのAPIとJunit5を組み合わせたUIテストが遂に書けるになりました。5に必要最小限の設定を記述しています。5も同一プロジェクトに設定して共存できますが、今回は割愛します。Testテストを書こうProjectソースはAndroid-Junit5/Instrumeny/Sample/から引用しています、ご参照ください。APIを使用可能になりました。5版@ActivityTestも廃止になりました。Resolution機能に対応している。そのため、ActivityScenarioは、直接テストケースのパラメータとして使うことができる。testでも使えます。テストの構造化、日本語の表示を実現できます。RepeatedTest指定した回数で繰り返しテストを実行できます。RepetitionInfoからcurrentRepetition(現在の実行回数)、totalRepetitions(実行すべき総回数)を取得できます。DisplayNameに対応している。ParameterizedTestParameterizedTestは異なる引数でテストを複数回実行できます。Argumentsアノテーションで宣言する。ソースアノテーションは複数種類ありますが、今回は展開せず@ArgumentsSourceを使う例を挙げます。テストメソッドのパラメータとしてデータを受け取ります。DisplayNameに対応している(今回は省略)。}テスト実行結果パラメタライズドテストは以下のような効果が考えられますRepeatedTestとParameterizedTestを活用して、重複するテストコード、テストケースを削減できます。argumentsを利用してにテストのGiven-When-Thenをペアに設定ことで可読性が上がります。Esspressoだけで画面上複数のビューの操作する時、テストコードがダラダラ長くなりがち部分も、arguments化して綺麗にまとまります。ご興味があれば試してみてください。android-junit5はまだリリースされたばかりなので、RepeatedTestとParameterizedTestの動作にはいくつか注意点がありますが、今回は割愛させていただきます。Lifecycleなど一歩進んだ使い方もあります。JUnit5のさらなる活用を使ってみましょう。参考リストhttps://github.com/mannodermaus/android-junit5/wiki/Instrumentation-Tests-Setuphttps://junit.org/junit5/docs/current/user-guide/謝辞@marcelschnellさんと共同開発者たちが素晴らしいプラグインを開発してくださって深く感謝しています。5に関して貴重な意見と経験を教えていただきました。ありがとうございます。発表・イベントリポートこんにちは、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内部で作成した自動テストの効能をまとめたドキュメントを参考にしながら作成しました。テストを書く習慣をつけるためには、そのメリットについて納得している必要があります。自動テストのメリットについて昨今のエンジニアであれば一度は聞いたことがあるかもしれません。普段テストが書きにくいプロダクト開発をしている場合、日常的に自動テストに触れられておらず、そのメリットの認識も曖昧になっているかもしれないと思いました。よって、なぜテストを書くのか?を改めて確認し、テストを書くモチベーションの向上につなげようという意図があり冒頭に説明をいれました。test)をまとめています。Androidテスト全書の1章を参考にしながら作成しました。この章はAndroidアプリ開発におけるテストの基礎知識を整理するために追加しました。TDDの紹介/TDDチュートリアルTDDは下記の点から題材として最適と思い採用しました。ハンズオンで使用した資料をアップしましたので、ご興味がある方はどうぞ!※外部公開に際し、資料は一部修正を加えております。Androidテストハンズオン基礎編TDDチュートリアルテストのないアプリにテストを書こうテストのないアプリにテストを書こう編のアウトラインは下記です。レガシーコードを改善しようレガシーコード改善に役立つ知識テストダブルレガシーコード改善テクニックテストのないアプリにテストを書こう(参加者に実際に手をうごかしてもらう)こちらもどうしてこのような構成にしたかを振り返ります。レガシーコードを改善しようこの章では、自動テスト実施状況アンケート結果で社内の半数がテストが書きにくい設計を課題としていることを紹介し、地道にテストを導入しつつテストが書きにくい設計を改善しようという提案をしました。目的は、タイトルの通りレガシーコード改善への動機づけです。テストが書きにくい部分に引きずられてテストを書かずにいると、悪循環になってしまうからです。レガシーコード改善に役立つ知識ここでは、テストダブルとレガシーコード改善テクニックの紹介をしました。Androidテスト全書の2章とレガシーコード改善ガイドを参考に作成しました。テストが書きにくい設計のアプリにテストを書いていくのは、なかなかに難易度が高いタスクです。テストダブルを使って依存を切り離すテクニックと、レガシーコード改善ガイドにある最低限の修正でテストを書けるようにするテクニックを知っていると、そのタスクの助けになると思いこの章を追加しました。テストのないアプリにテストを書こうあえてテストが書きにくい設計で実装したサンプルアプリを題材に、参加者にユニットテストを書いてもらうセクションです。Requestとして提出してもらい、SWETメンバーがレビューを行う方式にしました。ここでは、その前の章で説明したテストダブルやレガシーコード改善テクニックを、参加者が実際に使って身につけてもらうことを目的としています。Requestレビューを通じて説明した内容がきちんと伝わっているかと、参加者がお題にどのように取り組んだかを確認できるようにしました。資料こちらも実際にハンズオンで使用した資料の一部をアップしましたので、ご興味がある方はどうぞ!※外部公開に際し、資料は一部修正を加えております。平均4.78と良いフィードバックをいただくことができました。(5段階評価で5が良い・1が悪い)ハンズオンの内容の質にこだわったのはもちろん、専用のslackチャンネルを設けて質問をしやすくしたり、講師以外にもTAを3人配置するなどといった運営の工夫も功を奏したのだと思います。ハンズオンは好評のうちに終えることができましたが、実際にプロダクト状況を改善していくには継続的な取り組みが必要になります。参加者のテスト導入について相談を受けられるようにし、実プロダクトへの貢献も進めていきたいと考えています。今後もSWETでは社内のエンジニアがテスト技術について学ぶことができるコンテンツの作成を進めていきます。現在、下記を企画しています。ユニットテストハンズオンのiOS編モバイルのUIテストハンズオンGo言語でTDDを学ぶことができるCodelabこのような取り組みを通じて、社内のエンジニアが自動テストスキルを向上できる仕組みと、社内のエンジニアがいつでもテストについてSWETに相談できるような環境を作っていきます。最後に、SWETでは一緒に自動テストの普及に取り組んでくれるエンジニアを募集しています。発表・イベントリポートこんにちは。2019にSWETからは3名が登壇しました。参加メンバーが特に印象に残ったセッションをご紹介していきたいと思います!登壇者より自身のセッションについて一言マルチモジュールなプロジェクトでテストはどう変わる?登壇者の田熊(@fgfgtkm)です。このセッションでは私がマルチモジュールなプロジェクトでのテストを考えたときに、変えていく必要があると思った3点を紹介させていただきました。DIテスト方針メトリクスの収集DIのセクションでは、循環参照の問題や依存解決の定義をモジュール内に閉じ込めるため、これまでのやり方を変更しなければいけない可能性があることを話しました。Injection』のセッションを紹介させていただきました。私も拝見させていただき、とてもわかりやすく勉強になりました。テスト方針のセクションでは、モジュール単位で動作確認ができるようにテスト方針を考える、という話をしました。Nitrogenについて触れ、自動テストでカバーする領域を増やしていける環境が整いつつあることもご紹介させていただきました。最後にメトリクス収集について、複数のモジュールのレポートをまとめて見たい場合マージが必要になることと、PITというツールを例にどのようにレポートをマージするかについて話しました。想定していたよりも大きな部屋で多くの開発者に話をさせていただけることになったので、マルチモジュールというトレンドを取り入れつつも、これからテストにもっと力を入れていきたいと思っている方に下記のことを伝えられたらいいなと思いながら構成を考えました。自分のプロジェクトにどんなテストが必要かを考えるテストの環境や技術は日々進化しているテストに対する考えや知識をアップデートするきっかけになればとても幸いです。EspressoのテストをAndroidの最新トレンドに対応させよう登壇者の外山(@sumio_tym)です。次のようなトピックを解説しました。Objectsデザインパターンを適用する前提で解説しています。Objectsに書き換える様子をライブコーディングしている点が見どころです。気になる方は是非動画もチェックしてみてください。UIテスト(Espresso)の高速化をさらにすすめる登壇者の平田(@tarappo)です。2018の続編という形で「UIテストの高速化をさらにすすめる」というタイトルで登壇しました。UIテストの課題になりやすいものの1つに実行時間の増加があります。このUIテストの実行時間をどのように短くするかという話をしました。前回話した内容は実際に試してみるのがやや大変だったかと思いますが、今年の登壇内容は誰もがすぐに試せるようになっています。LabやFlankを試してみてもらえるとうれしいです。※動画はこちら登壇の際に、その先にある課題として自動テストがあることにより得られるred/green以外の情報などについても話しました。その課題については、どこかの機会で話せると嬉しいなと思っています。Test環境を手に入れろ!改めまして田熊(@fgfgtkm)です。今回はSpek関連のセッションが2つありましたので、それぞれご紹介させていただきます。Nishikoriさんのセッションです。こちらのセッションでは、SpekだけでなくKotlin製モックライブラリのMockKやコードカバレッジライブラリのJacocoなどトータルのユニットテスト環境について紹介されていました。※動画はこちらSpek2とMockKはどちらもKotlinフレンドリーな記述が可能で、Kotlinに慣れ親しんだ開発者がユニットテストを書き始めるときにとても導入しやすいと思っています。私のセッションでマルチモジュールなプロジェクトの場合レポートのマージが必要なことに触れましたが、こちらのセッションではJacocoでの具体的なマージ方法を紹介していました。それぞれの導入手順や使い方について丁寧に説明しているため、これからテスト環境を構築していく際の参考にすると良いと思いました。Morimotoさんのセッションです。Componentsを使用したクラスのテストをどのようにSpekで書くかを紹介していました。※動画はこちらSpekはテストコードの読みやすさから人気が高まっていると感じていますが、Androidが絡むとJUnitに比べて書き方のナレッジやサンプルが少ない印象です。セッションの中ではAndroid開発の中で採用されることが多いLiveDataとRoomのテストをSpekで書くための工夫が紹介されており、Spekで書けるテストの範囲を増やしていく際に役立つ知見の詰まったセッションだと思いました。build.gradle.ktsに移行しよう改めまして外山(@sumio_tym)です。こちらはtnjさんによる発表です。DSLへ移行する方法についての発表でした。DSLへ移行することで、IDEによるコード補完が効きやすくなるというメリットがあります。Gradleのビルドスクリプトでは、GroovyとKotlinを共存させることができます。その特徴を最大限利用して、徐々にGroovyからKotlinへ置き換えていくテクニックを分かりやすく解説していました。DSL化しようとして挫折した苦い経験があります。その当時を思い返してみると、着手する場所が悪かったがために、芋蔓式に全部Kotlin化せざるを得なくなったのが敗因でした。この発表で解説されている順番にしたがえば徐々に書き換えられるので、挫折せずにKotlin化を完遂できそうです。DSLへの移行を検討されている方は、是非参考にしてみてください。CI/CDチームの加瀬(@Kesin11)です。こちらのlitmonさんのセッションは、CIサービスやデプロイの自動化などに興味があるCI/CDチームとして、参加前から注目していました。※動画はこちら発表内容のメインは、それなりの人数で開発されているであろうアプリのリリース作業について人間が調整するのにコストが高くなりすぎたので、自動的に毎週リリースされるフローを構築したというものでした。Consoleのリリース前レポートでした。LabのRoboテストを直接利用することで同等のクラッシュ検知と通知は実現しているとのことでした。Consoleで使用されているのはこのRoboテストのようです。個人的な感想ですが、リリース作業を自動化するというフローはそもそもプロダクト全体の品質がかなり高い状態でないと、逆に検証不足でバグが頻出してしまうことも起こり得るのではないかなと思います。クックパッドでは以前から大規模にUIテストを含めた自動テストが行われているということをブログなどで拝見していたので、そのような積み重ねがあってこそ達成できるリリースフローなのかもしれません。この発表ではテストについての話はありませんでしたが、テストの必要性をより意識した発表でした。AutomationTestチームの鈴木です。Iijimaさんの発表をご紹介いたします。※動画はこちら本セッションでは、登壇者自身の実際の開発経験を踏まえながら、TDDによって得られるメリットについて解説されていました。ライブコーディングでTDDを実演しながら説明されていたので、初心者の方でも大きな抵抗なく読み進めることができると思います。内容はもちろん、説明の仕方もわかりやすく大変参考になりました。2019のセッションのうち、登壇者のセッションと各メンバーがそれぞれ印象に残ったセッションをご紹介しました。SWETグループでは、DroidKaigiでの登壇に限らず、積極的に対外的なアウトプットを行っています。Night(テストについて語り合う勉強会)も定期的に開催しております。Night(4月開催予定)の開催を予定しております。ご興味のある方は是非ご参加ください。SWETグループではAndroidに限らずテストの自動化やCI/CDに興味があり、私達と一緒に働いてくれる仲間を募集しています。(1)リンクプライバシーポリシースターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。