自分が考える最強のテストレポートを求めて

テストレポートは重要である。 それはフィードバックを正確に得るため。 正確なフィードバックは開発を加速させる。そして新たな気付きを得ることができる。

必要な機能、自分がほしい機能をまとめることで、最強のテストレポートを考察してみたい。

現状のテストレポートから

他のテストフレームワーク、テストレポートツール、他の人の発表資料を見ればそれらが見えてくる。

JUnit5

JUnit5はTestExecutionListenerをImplementしているクラスでテストレポートを作成できる。

通常、コンソールでテストレポートを表示するConsole Launcherは以下のようになる。

├─ JUnit Vintage
│  └─ example.JUnit4Tests
│     └─ standardJUnit4Test ✔
└─ JUnit Jupiter
   ├─ StandardTests
   │  ├─ succeedingTest() ✔
   │  └─ skippedTest() ↷ for demonstration purposes
   └─ A special test case
      ├─ Custom test name containing spaces ✔
      ├─ ╯°□°)╯ ✔
      └─ 😱 ✔

Test run finished after 64 ms
[         5 containers found      ]
[         0 containers skipped    ]
[         5 containers started    ]
[         0 containers aborted    ]
[         5 containers successful ]
[         0 containers failed     ]
[         6 tests found           ]
[         1 tests skipped         ]
[         5 tests started         ]
[         0 tests aborted         ]
[         5 tests successful      ]
[         0 tests failed          ]

取得できる情報は以下。

  • テスト名
  • テストステータス
  • グルーピング
  • 総実行時間
  • ステータスごとのテスト総数

Jest

以下、成功時の例。

 PASS  ./sum.test.js
  ✓ adds 1 + 2 to equal 3 (3ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.033s
Ran all test suites.

以下、失敗時の例。エラー時に対象のコードと詳細なエラー内容が出力されるのはよい。

 FAIL  ./sum.test.js
  ✕ adds 1 + 2 to equal 3 (5ms)

  ● adds 1 + 2 to equal 3

    expect(received).toBe(expected) // Object.is equality

    Expected: 4
    Received: 3

      4 |
      5 | test('adds 1 + 2 to equal 3', () => {
    > 6 |   expect(sum(1, 2)).toBe(4);
        |                     ^
      7 | });
      8 |

      at Object.<anonymous> (sum.test.js:6:21)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        1.385s
Ran all test suites.

ここには表示できてないが、実行中は何のテストをしているかとその経過時間が表示される。

Jestで取得できる情報は以下。

  • テストファイル名
  • テストケース名
  • テストステータス
  • 失敗した場所のコードとそのログ
  • グルーピング
  • 総実行時間
  • ステータスごとのテスト総数
  • (実行中)実行しているテストとその経過時間

Allure

取得できる情報は以下。テスト側に設定が必要な項目もある。非常に情報量は多い。

  • テストのステータス
  • テストのステータス比率
  • 実行環境
  • Suite
  • テスト数とそのステータスの推移
  • 環境情報
  • Category
  • 実行時間の推移
  • Severity
  • タイムライン
  • Behavior
  • Package
  • チケットリンク
  • テスト管理リンク
  • 添付(スクリーンショットや動画など)
  • エラーログ

f:id:AHA_oretama:20191122123825p:plain:w200 f:id:AHA_oretama:20191122123931p:plain:w200 f:id:AHA_oretama:20191122124004p:plain:w200 f:id:AHA_oretama:20191122124026p:plain:w200 f:id:AHA_oretama:20191122124045p:plain:w200 f:id:AHA_oretama:20191122124104p:plain:w200 f:id:AHA_oretama:20191122124121p:plain:w200 f:id:AHA_oretama:20191122124147p:plain:w200

ReportPortal.io

Allureと比較して目新しい情報はない。 テストレポート+ワークフロー(チケット管理とのインテグレーション、テストのパイプライン)の機能に価値がありそう。 唯一、他と異なるのはAIによりカテゴリ分けをしてくれること(過去のカテゴリと比較していると思われる)。

https://reportportal.io/features

UIテストレポートに関する発表資料

UIテストのレポータにフォーカスしているが、全体としてテストレポートに必要な機能がまとめられていてわかりやすい。

speakerdeck.com

ここまでのまとめ

  • ベースとなる機能(ログやテストステータス、実行時間)はほぼ共通で持っている。
  • レポートとしてフォーカスしているツールは、ダッシュボードやメトリクスなど可視性が高くなっている。

テストレポートの可能性

現状のテストレポートにはない機能だとしても有用な機能はあるはずである。 テストレポートの新しい機能の可能性について考えてみる。

新旧比較して過去のテストとの一致/類似度を表示させる

同じ原因のエラーが何度も表示される。 これはE2Eテストのように自身の関与が及ばない領域までテスト範囲に及んでいる場合に多いと思われる。

そのときに

  • 新規の問題なのか?それとも既知の問題なのか?
  • 既知の問題であれば、どのような問題と一致しているか?もしくは完全に一致しなくても類似度はどれぐらいか?
  • 過去に発生したのはいつか?何度発生しているか?

の情報が表示されると問題の解決が楽になる。

SLO の観点としてのテストレポート

テストは落ちたらすぐに治すべきものであり、それは絶対である。

しかしながら、そうできないものもあるもの事実である。 例えば、10回のうち1回ぐらい失敗するが、再現性が不明で原因がつかめないもの。 みなさんも経験があるのではないだろうか。

そのような場合に、SLOの観点を導入してみてはどうだろうか? 1テストケースに対する信頼性、テストケース全体での信頼性。 その信頼性を下回れば、他の作業を止めてでも問題解消につとめなければならない。 (もしくは該当のテストケースを削除する)

これを満たせなければ価値(後述)がないと判断できる。

価値としてのテスト

テストは資産である。資産であるが、それが正の資産か、負の資産(負債)であるかは判断がつかない。 またその資産を増やすか切り捨てる(テストケースを増やす、削除する)判断をするときに根拠が欲しくなる。

テストレポートで価値を定義してはどうか? 価値となりうるものは

  • テストケース数(コード数に対する)
  • カバレッジ
  • ドキュメント性
  • 実行回数
  • 信頼性
  • 実行時間

などが考えられる。

自分が考える最強のテストレポート

自分が考える最強のテストレポートには、テストレポートのベースとなる機能はMUSTであってほしい。

  • ログ
  • テストステータス
  • テスト時間
  • 全体のテスト結果
  • フィルタ、ソート
  • カバレッジ
  • スクリーンショット、動画(テストサイズSmall以外(後述))
  • 周辺環境のログ(テストサイズSmall以外(後述))

etc.

そして、それらにプラスしてテストレポートにすることの価値が上がる機能を全て盛り込んであるレポートであってほしい。

  • メトリクス(ダッシュボード)
  • SLO
  • 価値
  • 一致/類似度

etc.

そのようなテストレポートツールは残念ながら今のところ見当たらない。 時間があれば、自分が考えた最強のテストレポートを自分の手で作ってみたいところだ。

補足: UI テストレポート とUnit テストレポートでの違い

そこまで大きな違いはない認識。 ただし、UI テストでは連携している部分が多いため、その分必要なものが多くなる。

UI テスト とUnit テストでの違いというよりはGoogleのテストサイズによる違いといったほうが正確。

testing.googleblog.com

GoogleのテストサイズSmall以外(とくにLarge)では、インテグレーションする項目が増えるため、 それらに関する情報もテストレポートにあったほうがよい。 例えば、データベースのログやUIのスクリーンショットや動画など。