遵循 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 發布的軟體而定，CTF 測試會更加失敗，因為 Fuchsia 平台內部進行了不相關的變更。我們會依個案情形，將依附元件視為例外狀況。(例如，可在樹狀結構外運作的內部測試架構)。
使用不穩定的測試執行器進行測試時，必須攜帶自己的測試執行元件。
如要使用不穩定的測試執行器 (例如 Rust 測試) 進行測試，則必須透過子套件自行導入測試執行元件。如需詳細資訊和範例，請參閱 CTF 貢獻指南。
測試不應有不穩定的依附元件。
測試不得取決於可能消失、間歇性提供的功能，或僅適用於測試並非一律執行的特定平台。 包括網際網路伺服器和作業系統專屬檔案路徑等。
測試必須在 //sdk/ctf/tests 中實作。
如有疑慮，請傳送電子郵件至 fuchsia-ctf-team@google.com
測試應做為 API 使用方法的範例。
不過，如果某位開發人員想要查看測試，並複製該測試的 API 使用情況，測試作者就會相信開發人員能正確使用 API。測試應盡可能進行，而非仰賴未記錄的應用程式專用不變。日後，假如在 Fuchsia 樹狀結構外廣泛使用未記錄的使用情形，我們可能必須支援未遵循建議用途的用途。
測試不應有逾時。
並應由測試基礎架構強制執行逾時。
測試不得為壓力或效能測試。
我們不建議開發人員向 CTF 提交壓力測試或效能測試。我們會仔細檢驗這類測試來瞭解涵蓋率值。
測試應指定平台途徑的一個元素。
CTF 測試通常會直接指定平台介面區域的元素。如果其中一個失敗，應該清楚知道平台介面區域的哪些部分已觸發，以及變更的結果為何。這項規則通常會導致測試中的應用程式邏輯數量很少。
測試不應休眠。
在測試中，睡眠是導致不穩定的常見原因，因為每次執行的時間可能會因目標硬體和系統負載而異。我們建議開發人員建構程式碼，讓程式碼能在符合特定條件時傳送明確的信號，而不是讓部分測試的一部分等待其他程式碼完成。
測試應避免模擬或偽造目標裝置的內部狀態。
CTF 的用意是確保整個裝置都能正確運作，而不是確保特定元件獨立正常運作。
測試應運動邊緣案例和一般輸入和輸出。
範例包括整數的 0 和 MAXINT 值，以及指標值的空值指標。
測試應在測試完成後還原系統狀態。
舉例來說，如果測試要在整個系統上設定文字的背景顏色，便應在測試結束時將顏色重設為原始值。這可以防止測試互相影響。