TestDetta

自分のリポジトリで検証する

当社の評価はオープンソースのライブラリで行っています。ご自身のコードには独自のパターンがあるため、何を実行するかを TestDetta に任せる前に、そのコードで確認してください。通常どおりのプルリクエストで 2 週間ほどかかりますが、チームにとっては何も変わりません。

考え方

完全なテストスイートを引き続きゲートとして実行します。その横で、TestDetta なら何を選択したかを記録します。完全な実行で失敗したテストクラスは、すべてその選択に含まれていなければなりません。含まれていないものがあればそれは見逃しで、ぜひご報告ください。

手順

  1. 既定のブランチでマップを記録します。GitHub Actions ではワークフローの record ステップを追加します。それ以外では、既定のブランチへのコミットごとに td record を実行してマップを保持します（その他の CI システム）。
  2. プルリクエストごとに選択内容を書き出します。テストのステップは変更しません。 
    td affected --format json > selection.json
  3. 完全なテストスイートを今までどおり実行します。失敗を読み取れるよう、TRX レポートを出力します。 
    dotnet test --logger trx --results-directory TestResults
  4. 比較します。失敗したテストごとに、そのクラスが選択されていなければなりません。クラスが選択されているのは、そのプロジェクトの mode が All の場合、またはプロジェクトが Filtered でクラスが classes に含まれている場合です。 
    jq -r '.tests[] | select(.mode == "All") | .project' selection.json      # projects that run completely
jq -r '.tests[] | select(.mode == "Filtered") | .classes[]' selection.json  # classes that run
  5. 失敗したクラスが選択されていなかった実行については、両方のファイルを保存し、td affected の -v のログとともに support@testdetta.com までお送りください。

見逃しが明らかになるのは、テストが失敗したときだけです。2 週間では失敗がほとんど起きないこともあります。その場合は失敗を作り出せます。作業用のブランチでメソッドを意図的に壊し（誤った値を返すなど）、それを検出するテストが選択されることを確認してください。このブランチはマージしないでください。

確信が持てたら

完全なテストのステップを td test、またはアクションの test モードに置き換えます。既定のブランチでの記録は続けてください。そこではすべてのテストが実行されるため、選択によって隠れる可能性のあるものも、リリース前に必ず検出されます。

当社でのテスト方法

同じ確認を、41 件のオープンソースのリポジトリで大規模に実行しています。メンバーを 1 つずつ変更し、失敗したテストクラスはすべて選択されていなければなりません。テストを失敗させた変更 2,941 件のうち見逃しは 3 件で、それぞれ修正なしでは失敗するテストを添えて修正しました。コーパスの数値。