「最強」のチームを「造る」技術基盤　ディレクターズ・カット

「最強」のチームを「造る」技術基盤　ディレクターズ・カット

• 1.
  「最強」のチームを 「造る」技術基盤 ディレクターズ・カット -Android Test CasualTalksDec/13/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/
• 2.
  Hiroyuki Ito (伊藤宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2
• 3.
  Android Test CasualTalks 3
• 4.
  CI/CD TDD ATDD この３つを導入したお話を カジュアルにします 4
• 5.
  Agenda 1. 背景 2. 1stStage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 5
• 6.
  1. 背景 2. 1stStage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 6
• 7.
  1) スクラムのプロジェクトを始めたいというチームから、 アジャイルコーチとしてのサポート依頼を受けた 2) Androidの既存アプリのエンハンス • ベースはあるものの、実質新アプリの作成。 • 自動テストがなく、テスト・リリースは手作業。 3) 私自身、Android を（プログラム・端末含め） 一切触ったことがない • JavaEE の開発経験あるから、何とかなるだろ～ 7
• 8.
  超えるべき３つの壁 ここから WALL CI/CD WALL TDD WALLATDD こう攻めることにしました 8
• 9.
  1. 背景 2. 1stStage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 9
• 10.
  前提１ 既にある仕組みの活用 手作業でとはいえ、 ビルドやデプロイをする 仕組みはあった。 これを Jenkinsに肩代わりさせれば 良い。 10
• 11.
  前提２ 新たなアプリ配信の仕組み Android も使えるぞ～ スマートフォンのβ版アプリを チームメンバーへ配信できるサービス 丁度他のメンバーが試験導入をしていたため、 これとコラボを組むことにしました 11
• 12.
  具体的に実現した仕組み チェックインビルド （１時間おき） 私のノート PC チームメンバー全員に 最新版を配信 毎朝のデイリースクラムで、 最新版のアプリをステークホルダーに デモするようにしました 12
• 13.
  振り返り 既存システムの拡張で改善を始める場合は、 TDD や ATDDよりも、CI/CD を先にやった方が ROI が高いです。 • 品質の作り込みには、もちろん価値があります。 • 回帰テストの自動化は、繰り返しリリースをする場合には間違いなく 必要です。 • 一方で、触れるものを先に提示する方が、 直感的に「進んでいるな」と思われ易いことも事実です。 これは善悪の話ではなく、そこから攻めた方が 改善を進め易いという意味です。 13
• 14.
  1. 背景 2. 1stStage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 14
• 15.
  Before TDD Dao Dao DB Dao Model Controller DB DB Activity • 全コンポーネントを開発しないと（手動）テスト出来なかった。 •画面一式を開発するのに、それまでは１週間かかっていた。 15
• 16.
  Android の単体テストの課題 Android JUnit使い辛すぎるだろ（怒） • java.lang.RuntimeException: Stub! （ﾟДﾟ） • 単体テストなのに Emulator／ 実機を要求するな～ • コンポーネント単位での単体テストし辛いぞ～ ※Dao だけテストさせてくれ！ 16
• 17.
  解決策 ・Robolectric で、全ての UTを JVM 上で実行できる！ • http://robolectric.org/ • Emulator も実機も不要。 ・Test Double フレームワークとして、 Robolectric との相性の良い Mockito を活用。 • http://code.google.com/p/mockito/ 17
• 18.
  Robolectric で Daoの UT を行うイメージ @Before public void setUp() { Create database for Test; Insert test data; } @Test public void findXxx() { Assertions; } @After public void tearDown() { Drop Database for Test; } 18
• 19.
  After TDD Dao Dao DB Dao Model Controller DB DB Activity • 個々のコンポーネント毎に独立・分割して（自動）テストが可能に。 •画面一式を開発する期間を、１週間から１日に削減。 19
• 20.
  成果 1) フィードバックを迅速化できた。 • デグレをすぐに発見し、問題を解決できるようになった。 •Emulator・実機が不要なため、テストが非常に容易＆速い。 • 導入して４ヶ月以上経つが、Robolectric・Mockito 由来で 検証がうまく行かなかった箇所は特にない。 2) DB 周りを、開発の初期に一通り全て構築できた。 • UT 込みで一式完成させたため、 変更があっても容易に対応できるようになった。 3) 技術的にも心理的にも、エンジニアの負荷が減った。 • エンジニアが変更に積極的になった。 • 自発的にバグを見つけては解決してくれるようになった。 20
• 21.
  気付き Activity の UTも実施は可能だが、ROI は低い。 • 後述の Calabash-Android の方が、 ウチのチームでは ROI が高いです。 • 検証したい機能・粒度に合わせて 別々のツール・技術を利用しても問題はない。 テストカバレッジを１００％にすることや、 １つの方法に統一することが目的ではない。 テスト等を導入することで 開発を効率化出来ることの方が重要。 21
• 22.
  1. 背景 2. 1stStage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 22
• 23.
  なぜ ATDD か？ 1)Activity を JUnit でつくるのが面倒… • 皆さん Activity の UT って本当に出来てる？？？ 2) ユースケース／ユーザーストーリーを 自動テストしたい • Activity のテストは、デザイン除けばユースケース ／ユーザーストーリーのテストになることが多い。 3) 仕様がまとまりづらかったので、 テストケースから仕様をまとめようと考えた。 23
• 24.
  Calabash-android : Ouranswer • • • • Cucumber の Android 用 Wrapper です。 テスト仕様書を自動実行できるイメージです。 エンジニア以外でもテストケースをメンテナンスできます。 ビジネス・マネージャーが読めるため、 テストの妥当性を判断できます。 24
• 25.
  テストケースのイメージ Feature: Input Scenario: Inputtoday’s data Given I kick drumroll Then drumroll show today When press next Then I should see ”xxx" screen テストケースの名称です このレベルの記述で 自動実行できます When I press keys and calculator should show like this: | 2 | 2 | | 0 | 20 | | 0 | 200 | 読みやすさを考慮した | * | 200 | 記述ができます | 3 | 3 | | = | 600 | Then take photo … 25
• 26.
  試してみて分かったこと 1) 画面遷移やユースケースレベルのテストを、 繰り返し実行しやすくなった。 SmartPhone の場合、画面遷移・操作が複雑かつ複数のインタラクションを 含むことが多いため、UTよりは ATDD の方が ROI が高いと思います。 2) コミュニケーションツールとして有用。 • 外国人の開発メンバーに仕様を伝えるのが便利。 • ビジネスやデザイナーとの会話を整理することに使うこともある。 3) Silver bulletではない。 • 環境構築が意外と難しい。 • ライブラリが成熟していないため、そもそも自動化できない操作も多い。 • Excel のテスト仕様書の方が読んでくれる人が多い。 26
• 27.
  現在取り組んでいること 1) メンバーがやってくれたバグ対応は、 基本全て ATDD化する。 • 回帰テスト対策に加え、どういう仕様であるのかを動作＆ロジックで 後々説明しやすいため。 • メンバーの努力を形として残す、チームビルディングの一環でもある。 2) テスト仕様書はキチンと作る。 • 対象読者数を考えると、Excel のテスト仕様書はやはり必要。 • 読んでもらうにはテスト仕様書、実行はなるべく ATDD のように、 状況に応じて使い分けた方が良い。 3) テスト仕様書はキチンと作る。 大事なことなので２回言いました。 27
• 28.
  とはいうものの… Emulator が遅くて 検証が辛い（´･ω ･） 28
• 29.
  Genymotion! 1) VirtualBox 上で動作する、超高速Emulator です。 2) Calabash-Android からでも普通に使えます。 3) GPS やカメラも emulate できます。 4) 無料版があるので、試してみよう！ 29
• 30.
  1. 背景 2. 1stStage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 30
• 31.
  Android のテストの自動化のポイント 1) 仕事の効率化に焦点を絞ろう 2)自動化の導入自体を目的にしないようにしよう 3) 新しくてよいものは柔軟に取り入れよう 4) 簡単に失敗できるようにし、そこから学べるようにしよう 5) JavaEE の知識は使えるぞ！ 31
• 32.
  何のための 自動化か？ 32
• 33.
  Be happy! 33