遵循 Fuchsia 的最佳做法。
測試必須使用 //sdk/ctf/build 中的 ctf_* 規則變化版本。
CTF 測試的目標 API 和 ABI 可透過 SDK 取得。建構支援可確保測試僅仰賴透過 SDK 提供的 API 元素,或是已加入許可清單且可用於 CTF 的 API 元素。所有建構目標都必須使用 //sdk/ctf/build
中的 ctf_
規則變化版本,而非標準 fuchsia.git 規則 (也就是使用 ctf_fuchsia_component
、ctf_executable
等)。您可以在 //sdk/ctf/build/allowed_ctf_deps.gni
中找到非 SDK 程式碼的許可清單。如果測試作者認為需要額外納入,則應在 CTF 錯誤元件中回報錯誤。
測試可能取決於使用 SDK 發布的內容。
根據未透過 SDK 發布的軟體,由於 Fuchsia 平台內部環境不相關的變更,導致 CTF 測試較失敗。我們會依個案情況將依附元件視為例外狀況。(例如能在樹狀結構外運作的內部測試架構)。
使用不穩定的測試執行器進行測試時,必須使用自己的測試執行元件。
使用不穩定的測試執行器 (例如 Rust 測試) 進行測試,必須透過子套件自行導入自己的測試執行元件。如需詳細資訊和範例,請參閱 CTF 貢獻指南。
測試不應有不穩定的依附元件。
測試不應取決於可能會淘汰的項目、無法間斷的情況,或並非隨時執行測試的特定平台。例如網際網路伺服器和作業系統的特定檔案路徑。
測試必須在 //sdk/ctf/tests
中實作。
如果您有疑慮,請聯絡 fuchsia-ctf-team@google.com
測試應做為 API 使用範例。
一般而言,如果最終開發人員看到測試並複製了 API 的使用情況,測試作者就會認為開發人員會正確使用 API。測試應盡可能避免依賴未記錄、應用程式特有的變體。如果日後要廣泛使用 Fuchsia 樹狀結構外未記錄的用法,我們可能必須支援未遵循建議用法的用途。
測試不應設定逾時。
逾時設定改由測試基礎架構強制執行。
測試不應是壓力或效能測試。
我們不建議開發人員向 CTF 提交壓力測試或效能測試。我們會仔細審查這類測試的涵蓋率值。
測試應指定平台途徑區域的一個元素。
CTF 測試通常會直接指定平台介面區域的元素。如果其中一個失敗,系統應該就能清楚指出平台介面區域的哪些部分觸發了,以及變動結果。基於這個規則,測試中應用程式邏輯的數量會很小。
檢測不應進入休眠狀態。
睡眠是測試中斷裂的常見原因,因為在執行之間,時間可能會因目標硬體和系統負載而有很大的差異。我們建議開發人員建構程式碼,讓系統在符合特定條件時傳送明確信號,而不是讓部分測試需要一段時間等待其他程式碼完成。
測試應避免模擬或淡出目標裝置的內部狀態。
CTF 的用意是確保整部裝置都能正常運作,而不是確保特定元件獨立運作。
測試應運動極端案例以及一般輸入和輸出內容。
範例包括整數的值為 0 和 MAXINT,以及指標值的空值指標。
測試應還原測試完成後的系統狀態。
舉例來說,如果測試會對系統進行全系統的變更來設定文字背景顏色,就應該在測試結束時將顏色重設為原始值。以免測試互相影響。