要測試哪些項目與「是」測試相反，對於所有團隊來說都是相當重要的問題。測試只是要達成這個目的，但選擇程式碼集不同部分測試優先順序的方式可能並不容易。
決定優先順序的最佳方法是根據程式碼集和團隊的目標而定。但請務必記住，雖然在測試金字塔底部 (例如單元測試) 底部編寫大量程式碼測試所需的時間與頻寬並不需要，但不一定能降低專案的整體風險。
您可以先思考應用程式、網站或程式庫的主要用途，藉此選擇要先測試哪些項目。例如針對網站的重要部分 (也就是構成使用者體驗的核心元件) 編寫元件測試。舉例來說，如果網站允許使用者上傳及管理時間序列資料，開發人員就應該想像及測試使用者可能執行這些工作的不同方式。
另一個優先排序的方法，就是取得最豐富的資訊。如果您的程式碼集有「危險」、「老舊」或不當編寫的負載恐懼，且您的團隊沒有人喜歡參與工作，那麼在進一步忽略程式碼之前，建議您針對該部分建構測試，以使其行為更加一致，或重構並修正問題。這就像是為已組合而成，但仍有資料中心的員工架設鷹架。
維度
雖然我們採用了測試金字塔或其他測試形狀的概念，但這些概念通常只會顯示單一測試維度：從小型範圍、簡易單元測試到複雜的廣泛測試 (單元測試與整合測試與端對端測試)。
不過，有些可能的測試類型清單很長，無法代表某種程度的複雜度，而是代表測試目標或技術。舉例來說，煙霧測試是不同的測試類別，可以是單元、端對端或其他測試，但旨在讓測試人員整體相信測試中的專案處於有效狀態。視覺測試也適用於小型元件或整個網站。
程式碼集有獨特的需求。舉例來說，在程式碼集中對齊單一功能，可能更為重要，請撰寫不同類型的測試，確保功能可正常運作。需要測試的新功能很少只有單一元件、功能或方法，對專案的影響可能會很廣，並以不同的規模分佈。
您的測試優先順序也可能取決於業務需求。高技術系統可能需要進行複雜的單元測試，才能確認獨特的演算法是否正常運作，而高度互動的工具可能應專注於視覺測試或端對端測試，以確認複雜的觸控輸入能夠產生正確的回應。
測試方式
建議您專心測試程式碼集的用途，不受規模影響。請設想使用者可能會使用專案的任何部分，這可能代表單一元件、低階函式或高階端對端用途。(如果您發現測試無法與「測試中」的程式碼完美互動，這也可以顯示任何規模的抽象化缺陷。)
請務必為每個測試案例設定明確的目標。大型「通用」測試可能會並不容易，就像在非測試程式碼中一樣。
測試導向開發的結果
測試導向開發 (TDD) 是測試規模或類型的獨特測試方法，因為這牽涉到編寫要失敗的測試，至少要先編寫要失敗的測試。這同時適用於手動和自動測試：您可描述要達成的目標、找出目前解決方案或程式碼缺少的內容，然後使用失敗測試做為解決方案。
當然，在開始建構之前，測試假設應用程式或元件中的每個可能情境，都不是很實用的做法。TDD 具有地位，當您的程式碼集變得越來越複雜時，這項功能非常實用。
TDD 也很適合用來修正錯誤。如果您可以編寫重現某個錯誤的重現情況，系統可能會將問題納入自動測試，但一開始會失敗。修正錯誤後，測試會通過，讓您無需手動確認，就能判斷修正是否成功。
不透明與清除方塊
這是指您測試系統任一部分的方式。如果這種做法不透明，您就無法看到內部內容，例如使用類別的公開介面時，而非檢查其內部。
除非有特別原因，否則最好先進行不透明箱測試，以便根據元件的使用方式設計測試，不要因為內部元件的運作方式而受到干擾。如果只仰賴程式碼路徑的「公開」介面 (不一定會向使用者顯示，但或許會公開到程式碼的其他部分)，您可以重構並改善程式碼，知道測試會偵測到任何變更。
如要將「透明盒」程式碼轉換為更不透明的程式碼，其中一種方法是導入可設定的元素，例如程式碼依附元件的抽象化機制，或是用來觀察狀態的回呼，而不是該狀態與其他系統緊耦合。這樣做可以讓程式碼進一步分離，並讓您提供「測試」版本。或者，您也可以模擬程式碼與其他系統互動的位置。