我正在努力將盡可能多的邏輯移出自定義控件，以便它可以進行單元測試以減少手動測試負擔。我遇到了一種情況，即被測方法產生複雜的結果。編寫一個計算結果的測試用例將涉及將基本上是被測代碼寫入測試本身。如何編寫需要重複測試代碼的代碼測試？
例如，我有一個GeometryGenerator類，該類根據類的屬性創建WPF幾何。在一種配置中，生成由ArcSegment組成的PathGeometry。我可以根據測試參數計算弧的屬性，但是這個計算與我試圖測試的代碼是一樣的。這似乎會使測試失效;如果計算中存在缺陷，則測試中會存在缺陷，如果計算髮生變化，則可能在測試中更改。
我該如何處理這種情況？我想出的唯一方法是手動計算測試用例的結果並將這些值硬編碼到測試中。這是一個可以接受的方法嗎（看起來像我在執行之前編寫測試時所做的一樣）？
我想出的唯一方法是手動計算測試用例的結果並將這些值硬編碼到測試中。這是一個可以接受的方法嗎（看起來像我在執行之前編寫測試時所做的一樣）？
是的，這是典型的。爲了進行單元測試，您必須假定您用來計算結果的公式是正確的。這是您正在測試的軟件實施。
您預先計算了一些手工計算的結果，以確保您沒有使用測試代碼生成測試數據（單元測試中的一個非常糟糕的錯誤）。只要確保記錄測試用例，以便知道預期值代表什麼以及它們來自哪裏。
「單元測試」應該只是測試一個單元。所以最好你將有單獨的單元測試你的GeometryGenerator，另一個用於PathGeometry類，第三爲您ArcSegment等
通過測試每個單元seperately，你能獲得某種信心關於他們將如何表現當你用給定的一組輸入調用給定的操作時（GeometryGenerator在ArcSegment中的字段被設置爲1時的行爲方式，當相同字段被設置爲0時的行爲方式等）。
如果你的單元測試開始看起來像你正在複製現有的代碼來測試某些功能，那麼恐怕你正在做單元測試錯誤，並且有一個更簡單和更有效的解決方案。
手工計算和硬編碼在生產代碼中是不好的，但是對於良好的單元測試是必不可少的。
您通常希望爲代碼的每個「狀態」編寫一個測試。例如，我經常用正輸入，負輸入和零輸入編寫測試，以確保代碼正常工作。
通常情況下，我會做出一個神奇的數字，自文件，但被硬編碼，就像
const int的expectedResult = 2 * 4/someConstant; //也許是一個評論。
測試的讀者可以推斷出這些值是什麼，或者如果需要可以添加額外的註釋。