テスト分割のトラブルシューティング

並列コンテナ間にテストを分割すると、予期しない動作が発生する場合があります。これには多くの理由が存在します。 テストの並列実行の内容を十分に確認してください。

 

アーティファクトの保存

store_test_results ステップは、テストのタイミングが保存されたことを保証するものですが、これでデバッグが簡単になるわけではありません。 store_artifacts を使用してテストをアップロードし、実行されるテストの数を視覚的に確認できます。

 

テスト結果のエコー

アーティファクトの保存と同様に、クリーンなテスト分割コマンドを実装し、テストデータをエコー出力する方法の例を、以下に示します。

TESTFILES=$(circleci tests glob "test/**_test.rb" | circleci tests split --split-by=timings)
echo ${TESTFILES}
# bundle exec rake knapsack_pro:minitest
bundle exec rspec --format progress \
--format RspecJunitFormatter \
-o test/reports/rspec.xml \
-- ${TESTFILES}

Discuss の例: https://discuss.circleci.com/search?q=testfiles%3D%20category%3A48

 

最も速度の遅いテストの検出

RSpec など一部のテストライブラリは、"最も速度の遅いテスト" を報告します。

これらのテストを精査し、他のテストファイルと比較して長い時間を要するかどうかを確認することで、テストをより小さく、またはより効率的に行なえるようになります。

 

並列処理の変更

テストの作成方法によっては、並列処理の量を変更することでテストに大きな影響を与えることがあります。 また、繰り返し問題を引き起こしているテストはどれかを識別するためにも役立つことがあります。



タイミングの再同期

タイミングデータは、"グリーン" ビルドが成功したときに保存されます。 これらの結果はその後で、以前の数ビルドにわたって分析され、将来の分割のため使用されます。 これらの結果が偏っている、または他の理由で不正確な場合、問題を修正した後でも、ビルドのタイミングに影響を及ぼします。 問題が解決すると、以後の数ビルドにわたってタイミングデータが正規化され、予測される結果が得られるようになります。 この点を考慮し、数回のコミットをプッシュしてシステムをフラッシュします。 必要な場合、$CIRCLE_INTERNAL_TASK_DATA/circle-test-results でタイミングデータを確認できます。

 

可変長のテスト

テストが 1 つの場合もスイートの場合もあるので、完了時間は目的や他の多くの理由から大幅に異なります。 これは、UI または単体テストにおいて一般的です。 テストごとにタイミングが異なる場合、CircleCI の分割システムは有効なタイミングデータを判定できません。

 

分散ライブラリの検討

https://circleci.com/docs/2.0/parallelism-faster-jobs/#balancing-libraries

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています

コメント

0件のコメント

ログインしてコメントを残してください。