僕がテスト書け書けおじさんになった経緯とその過程でやったこと by yuyakaido at DroidKaigi 2016 を視聴した

視聴元

イントロ

• 納品優先で設計が疎かになる。
• テストコードなんて書いている暇はなし。
• で、後からテストを書こうとしても、テストを書けるような実装になっていない。

テストコードがないとどう辛いか

• Couplesというアプリの例 　- 膨大なテストケースを人力で確認
  • 50pのスプレッドシート
  • リリース前に影響範囲に対して人力確認
  • 各項目に対して5端末くらいを並べて動作確認
• 影響範囲の考慮漏れ→テストケースの複雑化
• 破綻した基盤設計
  • コピペの嵐
  • 全く関係なかったはずの箇所まで影響範囲に
  • テストケース間に依存関係が発生
• 人力じゃなくても、テストを簡単に自動化できる所はあるよね。
  • 例えば正常系。ボタンタップしたら画面遷移する程度。
• 問題点の整理
  • 膨大なテストケースとそれによる人的リソースの浪費
  • 影響範囲考慮ミスによるバグでユーザの離脱
  • テストケースの複雑化による人的リソースの浪費
  • 全て機会損失につながる。このままじゃスケールしないし、そもそもこれ以上は運用できない。なんとかしないと。

テストの方針

• UIは頻繁に変更する可能性あり
• まずは変更の少ないバックエンドから

でも、書けなかった

• マッチョなActivity/Fragment
• クラス間の依存関係が複雑
• 依存が複雑だからテストが書けない
• モックへの差し替えも難しい
• 既存のバックエンドに手を加えるのは怖いので、新しいバックエンドを作って乗り換え

依存関係の整理

• テストを書いて機能単位での置き換え→リスクを下げる
• テスタビリティの高い設計
• 各層の役割が明確である。(適切なモジュール化)
• CIサーバでの継続的なテストができる。
• 色々なアーキテクチャを検討
  • やりたいことはテストを書くことだから、こだわりどころじゃない
• バックエンドが綺麗になれば、それにつられてフロントも奇麗になるのでテストが書けそう

テスト手法・フレームワーク

ユニットテスト

• メソッド単位でのロジックの妥当性のテスト
• JUnit
• ロジックだけならこれだけで十分

UIテスト

• ユーザ操作を含めたテスト
• Espresso
• 実機でやる必要がある
• 人力と同じくらいの時間がかかるらしい

フレームワーク

• Robolectric
  • UIの動きを含めたテストが書ける
  • 実機を必要としない
  • API21までしか公式でサポートされていない
• DroidKaigiのサンプルアプリでのテストコードの紹介
  • RxJavaでの処理など
• MockWebServer
  • WebサーバをMock化できる
  • Square製
• Mockito
  • ユニットテスト用のモックライブラリ
  • 呼び出し確認や返り値をチェックする

テストを書く文化を作るために

• 週1回の勉強会を開催
• 全員の技術レベルがまちまちで、テストが書ける環境を作るだけでは不十分。
• 正直これが一番重要。

勉強会の内容

• アーキテクチャについて
• アーキテクチャの概要
• ライブラリ
• 一般的なテストについて
• ソフトウェアテスト
• ホワイト・ブラックボックステスト
• 同値・境界値
• 命令・分岐・条件網羅

最後に

• テストが目的化してはダメ。書いて満足してはダメ。
• 楽をしたい。
• エンジニアは怠惰であれ。
• テストを書くことで有益なことに業務時間を使えれば、それって幸せだよね。