testthat
パッケージ内のコードをチェックするために使用しています。私のテストのいくつかは、コンストラクターやゲッターなどの基本的な機能用です。その他は、基本機能の上に構築される複雑な機能用です。基本的なテストが失敗した場合、複雑なテストが失敗することが予想されるため、それ以上テストする意味はありません。
次のことは可能ですか。
- 基本的なテストが常に最初に行われるようにする
- テスト失敗でテスト プロセスを停止する
testthat
パッケージ内のコードをチェックするために使用しています。私のテストのいくつかは、コンストラクターやゲッターなどの基本的な機能用です。その他は、基本機能の上に構築される複雑な機能用です。基本的なテストが失敗した場合、複雑なテストが失敗することが予想されるため、それ以上テストする意味はありません。
次のことは可能ですか。
あなたの質問に答えるには、ファイルに適切な英数字の名前を付ける以外に判断できないと思いtest-*.R
ます。
ソースからtestthat
、これは test_package が test_dir を介してテストを取得するために呼び出す関数です。
find_test_scripts <- function(path, filter = NULL, invert = FALSE, ...) {
files <- dir(path, "^test.*\\.[rR]$", full.names = TRUE)
とにかく、複雑なタスクを最初に失敗させて何が悪いのでしょうか?
並列テスト処理である test への最近の (っぽい) 開発
テスト間に複雑な相互依存関係があるように聞こえるため、これはあなたのケースには適していない可能性があります。テストを分離することができれば (いずれにせよより一般的なケースだと思います)、並列処理は優れたソリューションです。全体の処理時間を短縮し、おそらく「遅い」テストの前に「速い」テストが失敗することを示すはずだからです。テストが完了しました。