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