Rust 測驗的檔案表明，當定義單元測驗的模塊在范圍內時運行單元測驗，并激活測驗配置標志：
#[cfg(test)]
mod tests {
#[test]
fn it_works() {
let result = 2 2;
assert_eq!(result, 4);
}
}
然而，在大型專案中，經常將測驗模塊限制在不同的檔案中，以便測驗模塊以不同的方式指向：
#[cfg(test)]
#[path = "unit_tests/tests.rs"]
mod tests;
使用此設定，在大型專案中，可能有人洗掉了對（即上面的代碼塊）的參考，而沒有洗掉測驗檔案本身。src/unit_tests/tests.rs這通常表示一個錯誤：
- 洗掉是故意的，并且檔案
src/unit_tests/tests.rs不應保留在存盤庫中， - 或者不是，在這種情況下，測驗
src/unit_tests/tests.rs應該運行而不是運行，CI 應該對此發表意見。
我想在我的專案的 CI 中添加一個驗證，即我的 crate 中沒有這樣的 unmoored 測驗檔案。rust 生態系統中是否有任何工具可以幫助我以編程方式檢測那些未鏈接的測驗檔案？
（如果在 crate 的存盤庫中找到集成測驗，則會自動編譯tests/，但 IIUC，不適用于單元測驗）
uj5u.com熱心網友回復：
有一個問題要求 cargo 執行此檢查，cargo (publish) 應該抱怨未使用的源檔案，并且從中發現cargo-modules crate 可以執行此操作。例如：
//! src/lib.rs
#[cfg(test)]
mod tests;
//! src/tests.rs
#[test]
fn it_works() {
let result = 2 2;
assert_eq!(result, 4);
}
> cargo modules generate tree --lib --with-orphans --cfg-test
crate mycrate
└── mod tests: pub(crate) #[cfg(test)]
但是，如果我洗掉#[cfg(test)] mod tests;輸出將如下所示：
> cargo modules generate tree --lib --with-orphans --cfg-test
crate mycrate
└── mod tests: orphan
您將能夠grep為“孤兒”并基于此而使您的檢查失敗。
我會說，從我的小測驗來看，這個工具似乎很慢。鏈接問題中的討論表明，如果在貨物中實施，則必須使用更好的方法。
您還必須記住，任何其他條件編譯都可能產生誤報（即，您根據架構、作業系統或功能合法地包含或排除某些模塊）。有--all-features一面旗幟可以幫助解決其中的一些問題。
uj5u.com熱心網友回復：
關于這個主題有一個非常古老的 rustc 問題，它仍然是開放的。
然而，其中一位評論者提供了一個技巧：
實作這一點的一種可能方法（包括作為第三方工具）是決議 rustc 為貨物發出的 .d 檔案，并查找任何未提及的 .rs 檔案。
rg --no-filename '^[^/].*\.rs:$' target/debug/deps/*.d | sed 's/:$//' | sort -u | diff - <(fd '\.rs$' | sort -u)
顯然.d檔案是
makefile 兼容的依賴串列
所以我認為他們應該列出專案中所有 rust 檔案之間的關系。這就是為什么如果一個丟失，它不會被 cargo / rustc 看到。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/513964.html
標籤：单元测试锈货物
上一篇：錯誤：無法檢測到網路[jest][ethers][javascript]
下一篇：如何映射未知物件鍵的陣列