開発途中からテストを導入する話です。

1. テストがあればなんとかなる
〜効率化までの道程〜
Takao Sumitomo
@cattaka_net

2. 自己紹介
●
住友 孝郎(Takao Sumitomo)
●
Androidアプリ開発者
●
開発経歴
●
Androidアプリケーション(4年)
●
iOS(3ヶ月)
●
業務系Webアプリケーション
●
Enterprise Windows app
●
その他
– 電子工作
– OpenCV
●
ウォンテッドリー株式会社所属

3. プロの力が身につく
Androidプログラミングの教科書

4. 駄目コードについて、C87で書きました
技術サークル
TechBooster

5. 開発途中から
テストを導入する話をします

7. ベストアプリに選ばれました

8. 開発体制
●
実装
●
自分
●
テスト
●
自分
● QA
●
自分
●
リリース担当
●
自分

9. Wantedlyのアプリ
●
WebやiOSに遅れて開発
●
まだまだ成長途中です
●
これからがんばる

10. これまでとこれから
●
まずはリリース(2014年5月〜)
●
本格的に改修開始(12月〜) ←ここで参戦
●
海外展開へ(2015年3月〜)

11. 参戦時の状態
●
試験的に作ったアプリだったため
●
あるのはコードのみ
●
テストコードは存在せず
●
何が正しいのかわからない
●
触ると何処か崩れそう、、

12. やったこと
●
最小限のリファクタリング
●
外部依存やストレージ周りにオレオレDIを入れる
– 通信処理
– データベース
– プリファレンス
●
その他 (個人的に過去に関わったアプリの事例)
●
不要なグローバル変数を取る
– シングルトンという名のグローバル変数も取る
●
投げっぱなしのスレッドを止める
●
Process.killProcessなどを止める
●
ひたすらテストを書く

13. ひたすらテストを書く

14. 具体的な修正1
●
修正前
アプリケーション
通信処理データベース
SharedPreferences

15. 具体的な修正2
●
修正後
アプリケーション
通信処理データベース
SharedPreferences

16. 具体的な修正3
●
テスト時の構成
アプリケーション
通信処理のモックデータベースのモック
SharedPreferencesのモック

17. 具体的な修正3
●
テスト時の構成
アプリケーション
通信処理のモックデータベースのモック
SharedPreferencesのモック
要はこれらをモックに
差し替えられれば
テストが書ける

18. オレオレDIでも無いより良い！
プロダクションコード
public class SharedPreferencesFactory {
static SharedPreferencesFactory INSTANCE = new SharedPreferencesFactory();
public static SharedPreferencesFactory getInstance() {
return INSTANCE;
}
public SharedPreferences newInstance(Context context, String name) {
return context.getSharedPreferences(name, Context.MODE_PRIVATE);
}
}
テスト用のダミー
public class DummySharedPreferencesFactory extends SharedPreferencesFactory {
public SharedPreferences newInstance(Context context, String name) {
return context.getSharedPreferences("test_" + name, Context.MODE_PRIVATE);
}
}
テストのときは
ここをダミーに差し替える

19. データベースの差し替え
●
RenamingDelegatingContextを使えば
一時的に別のDBファイルにできる
●
SQLiteOpenHelperにcontext=nullを渡すと
オンメモリのデータベースが作れる
どっちでもテストは書ける

20. 通信処理の差し替え
●
予め通信処理は１つにまとめておく
●
オレオレDIで通信処理を差し替える
●
偽の通信データを返すようにする
●
偽の通信データは
androidTest下のassetsに入れる

21. ひたすらテストを書く
●
ブラックボックステスト
●
ウォークスルー
●
コンバージョンに繋がるところを重点的に
●
ログイン周り
●
応援
●
応募
●
ユーザーのプロフィール入力

22. ひたすらテストを書く

23. 悲しいこともあるけど、、

24. ツールやライブラリ

25. 基本的に一般的なものを使用
●
JUnit4
●
./gradlew connectedAndroidTest
●
./gradlew createCoverageReport
●
Espresso (android-test-kit)
●
UI周りのテストが簡潔に書ける
●
Mockito
●
モックが簡単に作れる
●
Crashlytics

26. connectedAndroidTestのレポート

27. createCoverageReportのレポート

28. 標準でも十分強力

29. 今後の予定
●
CIで自動化
●
Jenkins? Travis CI? Circle CI? 検討中
●
実はまだテストは手でgraldewを叩いてる

30. まとめ

31. いきなり効率化は無理

32. テストがあればなんとかなる

33. まずはテストを書こう

34. ご清聴ありがとうございました
Takao Sumitomo
@cattaka_net