Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How To Remodel Current Testing Environment

How To Remodel Current Testing Environment

Day1, DroidKaigi 2017

Matsuda Jumpei

March 09, 2017
Tweet

More Decks by Matsuda Jumpei

Other Decks in Programming

Transcript

  1. How To Remodel
    Current Testing Environment
    Day1, DroidKaigi 2017

    View full-size slide

  2. はじめに
    本発表はIEEE829やウ



    29119には準拠してい
    ません
    (喧嘩を売るつもりもありません)

    View full-size slide

  3. About me
    Jumpei Matsuda
    Working at Quipper Limited
    twitter/@red_fat_daruma, github/jmatsu

    View full-size slide

  4. 既存のテストの価値・役割を理解してま
    すか?

    View full-size slide

  5. テストの価値・役割
    精神的保険?
    テストありきの開発?
    仕様と同等?

    View full-size slide

  6. テストを精神的保険とする開発
    テストは精神的安定のために存在している
    アプリの動作保証 < 精神的安定
    失敗すると「直すのが面倒くさい」が先行する
    最悪、あとで直せばいい
    テスト = 自己満足

    View full-size slide

  7. テストありきの開発
    Test Driven Development
    段階受け入れテストを用いた開発

    View full-size slide

  8. Test Driven Development
    テストの作成・実行を開発サイクルに組み込む
    1. ユニットテストを書く (実行すると fail する)
    2. ざくっと実装する
    3. ユニットテストが通る
    4. 合意を得られるまでリファクタリングする
    5. 1~4を繰り返す
    テスト = 開発プロセスを構築するファクター

    View full-size slide

  9. 段階受け入れテストを用いた開発
    各段階テストの受け入れがリリースの条件
    JUnit test
    Android Instrumentation test
    UI test, happy path test, scenario test
    テスト = Quality Assurance

    View full-size slide

  10. 仕様と同等なテストを用いた開発
    Behavior Driven Development
    基本的にDSLを用いて記述
    フレームワークの制約がつく
    Given, When, Then
    初期コンテキスト, 契機イベント, 結果の保証
    テスト = 仕様

    View full-size slide

  11. 既存のテストの価値・役割を説明でき
    る?

    View full-size slide

  12. Room3 @Nkznさんによる
    React Nativeの話が面白いと思います

    View full-size slide

  13. How To Remodel
    Current Testing Environment

    View full-size slide

  14. Model/‑ing と Re‑model‑ing

    View full-size slide

  15. Model
    抽象化により知り得た側面や性質を持つ構造・
    外観
    Model‑ing
    特定の側面や性質を持つ構造・外観を作ること

    View full-size slide

  16. Remodel‑ing
    既存モデルの変更により、目的のモデ
    ルを得ること
    リファクタリングではない

    View full-size slide

  17. Remodelingにより得たい恩恵
    テストの信頼度向上
    テスト負債の返上
    テストの安定化
    欠落したテストの補完
    不必要なテストの削除

    View full-size slide

  18. Remodelingのステップ
    1. 現存するテストの理解・掌握
    2. 目的モデルの選定
    3. 目的モデルの構築

    View full-size slide

  19. Remodelingのステップ
    1. 現存するテストの理解・掌握
    2. 目的モデルの選定
    3. 目的モデルの構築

    View full-size slide

  20. 現存するテストの理解
    e.g. タイムアウトを利用した検証
    I
    T
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y t
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y = m
    o
    c
    k
    (
    )
    ;
    I
    A
    u
    t
    h
    U
    s
    e
    C
    a
    s
    e u
    c = n
    e
    w A
    u
    t
    h
    U
    s
    e
    C
    a
    s
    e
    (
    t
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y
    )
    ;
    u
    c
    .
    r
    e
    q
    u
    e
    s
    t
    L
    o
    g
    I
    n
    (
    u
    s
    e
    r
    I
    d
    , p
    a
    s
    s
    w
    o
    r
    d
    )
    ; /
    / a
    s
    y
    n
    c e
    x
    e
    c
    u
    t
    i
    o
    n
    T
    h
    r
    e
    a
    d
    .
    s
    l
    e
    e
    p
    (
    3
    0
    0
    0
    )
    ;
    M
    o
    c
    k
    i
    t
    o
    .
    v
    e
    r
    i
    f
    y
    (
    t
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y
    )
    .
    c
    r
    e
    a
    t
    e
    (
    a
    n
    y
    (
    )
    )
    ;

    View full-size slide

  21. 現存するテストの理解
    e.g. タイムアウトを利用した検証
    I
    T
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y t
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y = m
    o
    c
    k
    (
    )
    ;
    I
    A
    u
    t
    h
    U
    s
    e
    C
    a
    s
    e u
    c = n
    e
    w A
    u
    t
    h
    U
    s
    e
    C
    a
    s
    e
    (
    t
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y
    )
    ;
    u
    c
    .
    r
    e
    q
    u
    e
    s
    t
    L
    o
    g
    I
    n
    (
    u
    s
    e
    r
    I
    d
    , p
    a
    s
    s
    w
    o
    r
    d
    )
    ; /
    / a
    s
    y
    n
    c e
    x
    e
    c
    u
    t
    i
    o
    n
    T
    h
    r
    e
    a
    d
    .
    s
    l
    e
    e
    p
    (
    3
    0
    0
    0
    )
    ;
    v
    e
    r
    i
    f
    y
    (
    t
    o
    k
    e
    n
    R
    e
    p
    o
    s
    i
    t
    o
    r
    y
    )
    .
    c
    r
    e
    a
    t
    e
    (
    a
    n
    y
    (
    )
    )
    ;
    3000ms という値に意味はある?

    View full-size slide

  22. 現存するテストの理解
    e.g. タイムアウトを利用した検証
    非機能要件との関係を疑う
    3000ms 以内にレスポンスを返すべきという要件
    テストコードとして 3000ms には意味がある
    非機能要件にない
    C
    o
    u
    n
    t
    D
    o
    w
    n
    L
    a
    t
    c
    h や F
    u
    t
    u
    r
    e
    #
    a
    w
    a
    i
    t の方が適切

    View full-size slide

  23. Modelingの要素例
    運用的側面
    テストポリシー・ストラテジー
    要件保証
    手動 or 自動
    技術的側面
    言語・フレームワーク・実行環境
    分類・頻度
    Mock‑able and/or Inject‑able

    View full-size slide

  24. 運用的側面
    テストポリシー・ストラテジー
    要件保証
    手動 or 自動

    View full-size slide

  25. テストポリシー
    組織の視点から見た「原則・目的」
    PMやEXEの理解が必要
    テストストラテジー
    テスターなどのステークホルダーに必要な側面
    テスト環境等
    ポリシーに基づいた上で、テストレベル別に用

    View full-size slide

  26. 考えたくないくらい定義が重いので
    この定義は使いません

    View full-size slide

  27. テストポリシー
    プロジェクトにおけるテストの意味・役割
    テストストラテジー
    ポリシーを基にした、テスト作成・実行に必要
    な要件
    受け入れ基準や手法、テスト環境など
    テストケースの仕様ではない
    テストレベルごとに存在

    View full-size slide

  28. テストポリシー・ストラテジー
    テストの意味・役割・手法の理解を支援
    どの要件を満たすためのテストか
    開発者間での認識の共通化を支援
    どのようなテストを書くべきか
    テストポリシー・ストラテジーが用意できない
    ⇒ 開発者それぞれでテストに対する価値認識が異なる可
    能性

    View full-size slide

  29. 運用的側面
    テストポリシー・ストラテジー
    要件保証
    手動 or 自動

    View full-size slide

  30. 要件保証 ‑ とある教育系アプリ
    生徒用・教師用(保護者用)のサービスが共存
    e.g.) ビジネス要件
    2サービス間に成績表示の差異がない
    課題の正答率がプラットフォームに依存しない
    オフラインでも動作して欲しい
    ビジネスロジック・永続化ロジックを保証した

    View full-size slide

  31. 運用的側面
    テストポリシー・ストラテジー
    要件保証
    手動 or 自動

    View full-size slide

  32. 手動 or 自動
    ⇒ 労働コストと金銭コストのせめぎ合い
    手動
    人の命を削れば実現できる
    ヒューマンエラーの入る余地がある
    自動
    実行環境自体に金がかかる
    自動テストコードの技術的ハードル

    View full-size slide

  33. 技術的側面
    言語・フレームワーク・実行環境
    サイズ・頻度
    Mock‑able and/or Inject‑able

    View full-size slide

  34. 利用言語・フレームワーク
    Java, Kotlin, Groovy?
    JUnit, Spek, Spock?
    Robolectric, mockable‑jar?

    View full-size slide

  35. 実行環境
    実機・エミュレータ
    リソース的に自由に利用できる環境が必要
    Robolectric (Robospock)
    マシンのJDKとShadowでエミュレートする
    Java SL実装やNative Libraryが違う

    View full-size slide

  36. 技術的側面
    言語・フレームワーク・実行環境
    分類・頻度
    Mock‑able and/or Inject‑able

    View full-size slide

  37. 分類の例 : Test Size
    https://testing.googleblog.com/2010/12/test‑sizes.html
    Feature Small Medium Large
    Network access No localhost only Yes
    Database No Yes Yes
    File system access No Yes Yes
    Use external systems No Discouraged Yes
    Multiple threads No Yes Yes
    Sleep statements No Yes Yes
    System properties No Yes Yes
    Time limit (seconds) 60 300 900+

    View full-size slide

  38. 分類の例 : テストの段階
    Unit test
    Android Instrumentation test
    UI test
    happy path test
    scenario test

    View full-size slide

  39. 技術的側面
    言語・フレームワーク・実行環境
    分類・頻度
    Mock‑able and/or Inject‑able

    View full-size slide

  40. Mock‑able or Inject‑able
    Mockable
    Test Doubleの思想が導入できる
    Injectable
    テスト用のクラスに置換できる

    View full-size slide

  41. Test Double
    名称 用途
    Dummy ただの引数埋めオブジェクト
    Fake 本番には不適な一時実装
    Stub 静的な値を返す実装
    Spy 呼び出し情報を記録する実装
    Mock 期待動作の登録と検証が可能

    View full-size slide

  42. Test Doubleの思想が導入できる
    ⇒ Doubleの取捨選択が可能
    ストラテジーやオブジェクトの用途に依存
    e.g. WhiteBox or BlackBox
    某有名ライブラリであるMockitoは?
    MockとSpyの利用が多い
    上記2つの"使い分け" がテストコードに意味を持た
    せる

    View full-size slide

  43. Injectable
    テスト用のクラスに置換できる
    DIツールを利用していることとは違う
    ぬくもり溢れるconstructor injection
    ぬくもり溢れるSetter

    View full-size slide

  44. Remodelingのステップ
    1. 現存するテストの理解・掌握
    2. 目的モデルの選定
    3. 目的モデルの構築

    View full-size slide

  45. e.g. とある教育系アプリのモデリング
    運用的側面
    DB操作・プレゼンテーション前の変換層をテスト
    ビジネス要件の保証が最重要
    分類は特になし
    普段はCIでテストを回す
    リリース時は手動のhappy path

    View full-size slide

  46. e.g. とある教育系アプリのモデリング
    技術的側面
    Unit test (on all branch)
    Groovy + Robospock
    Instrumentation test (on master/release)
    Java + Emulator
    Mockableだけど、Injectableとは言えない
    Constructor Injectionはあまりない
    初期化時に処理が発生し、Setterでは対応不可

    View full-size slide

  47. Remodelingのステップ
    1. 現存するテストの理解・掌握
    2. 目的モデルの選定
    3. 目的モデルの構築

    View full-size slide

  48. とある教育系アプリ (再掲)
    生徒用・教師用(保護者用)のサービスが共存
    ビジネス要件の例
    2サービス間に成績表示の差異がない
    課題の正答率がプラットフォームに依存しない
    オフラインでも動作して欲しい
    ビジネスロジック・永続化ロジックを保証した

    View full-size slide

  49. ビジネスロジック・永続化ロジックの保

    ⇒ Given, When, Thenが明確
    ⇒ BDDがうまくハマる

    View full-size slide

  50. ビジネスロジック・永続化ロジックの保

    ⇒ Given, When, Thenが明確
    ⇒ BDDがうまくハマる
    ≠ BDDを導入できる

    View full-size slide

  51. BDDの導入実現性
    Mockable and Injectable を満たすべき
    満たしていないなら・・・?
    リファクタリングする
    他の手法にする

    View full-size slide

  52. とある教育系アプリでは・・・
    Constructor Injectionへ変更
    Dagger2を一部で利用
    基本的にWhiteBoxテスト
    細かい分岐は「開発者が知るべき知識なため」
    Robospockは利用継続
    UIテストの追加
    ログイン・登録周りの保証のため
    金で殴れば解決する事項は金で解決

    View full-size slide

  53. とある教育系アプリでは・・・(今後)
    DIツールの適用箇所増加
    Robolectricの排除
    OpenSTFを使う(現在移行作業中)
    マルチモジュール化
    ビジネスロジック+テストの抽出
    テストフレームワークを切り替えられる
    お金を稼いでさらに金で解決する

    View full-size slide

  54. まとめ
    テストの価値・役割を理解する
    既存環境のモデリング
    運用的側面と技術的側面を捉える
    目的モデルを選定する
    保証すべき要件からボトムアップで作成
    目的モデルの構築
    必要なら先にリファクタリングをする

    View full-size slide