在編寫測試時，其中一些測試有很多邏輯。這些邏輯大部分可以很容易地進行單元測試，這將提供更高級別的測試信任。測試單元測試的輔助方法
我可以看到一個辦法做到這一點，這將是創建一個類TestHelpers，把在/班，並寫出TestHelpers測試與常規測試一起。
我無法找到在網絡上的這種做法發表任何意見，可能是因爲關鍵字的問題是棘手（「用於測試測試」）。
我想知道這是否聽起來很好的做法，人們是否已經做到了這一點，是否有對任何意見，這是否指向糟糕的設計，或者類似的東西。
我遇到了這個而做特性測試。我知道它有一些框架，但是我自己寫它，因爲它不那麼複雜，並且使我更清晰。另外，我可以想象，單元測試可以很容易地遇到同樣的問題。
舉個例子，在某些時候我正在測試一個連接到Twitter的API服務和檢索數據的函數。爲了測試數據是否正確，我需要測試它是否是json編碼的字符串，結構是否與twitter的數據結構匹配，每個值是否具有正確的類型等。執行所有這些檢查與檢索的數據的函數通常會自行測試。
對這種做法有何想法或意見？
我認爲測試自己太多了。 alfasin正確，那麼誰會爲測試測試測試呢？並不是巧合，你無法找到關於這個主題的更多信息。這是因爲這不是一種常見的做法。通常，寫得很好的測試應該涵蓋測試本身的排列邏輯。但我理解你的願望 - 如何確保測試「寫得很好」？這裏最危險的是通過測試，通常應該失敗（但由於錯誤而通過）。進行這樣的測試甚至比根本沒有測試更糟糕。但說實話，我在實踐中並沒有太多這樣的情況。我的建議是隻專注於寫作，涵蓋你的邏輯的所有執行路徑良好的測試，我想你會沒事的:)
一個關於TDD的格言是，「測試測試代碼，而該代碼測試測試「。也就是說，由於紅綠重構循環，您會看到代碼在測試中失敗，然後在使其運行後，您會發現它通過了測試 - 而且這足以讓您相當確信測試（和它調用的所有測試實用程序代碼）工作正常。對於特性測試，您沒有這個紅綠重構循環，因此您可以爲您的測試實用程序方法編寫測試。
雖然這聽起來很反常，我也偶爾寫一些我的測試基礎設施，如果它變得相當複雜的自動化測試。測試這種測試基礎設施的測試往往很簡單，所以「測試測試測試怎麼樣？」根據我的經驗，問題變得沒有意義。
請注意，這主要發生在爲了幫助測試其他人（在這種情況下編寫Qt應用程序的人）而明確設計的庫中，儘管之前我已經爲某些獨立應用程序完成了它：例如，在編寫測試Kate的Vim模式的自動完成集成，用於模仿各種配置的自動完成的假自動完成程序測試幫助代碼已經足夠複雜了，以至於我實際上已經開始開始測試優先。
可能值得一提的是，例如， Google Mock有數百個爲它編寫的測試:)
什麼將測試您的測試測試？ :) – alfasin