TDD和報告的最佳實踐

Question

我想更加熟悉測試驅動的方法。我的一個缺點是我的代碼的主要部分是生成報告的上下文（PDF文檔，圖表圖像）。總是有一個複雜的設計人員參與其中，並且不存在正確性的簡單測試。沒有機會測試片段！

你知道這種情況下的TDD實踐嗎？

Answer 1

您可以使用驗收測試驅動開發來替換單元測試，並具有用作參考的已知數據的驗證報告。

然而，這種測試並沒有像單元測試那樣給出細粒度的診斷，他們通常只提供PASS/FAIL結果，並且如果報告經常變化，則需要重新生成和重新驗證以及。

Answer 2

您可以嘗試爲報告數據源使用Web服務並測試該服務，但是您不會爲渲染進行單元測試。這與測試視圖時的問題完全相同。當然，你可以使用像Selenium這樣的網絡測試框架，但是你可能不會實踐真正的TDD。代碼完成後，您將創建測試。

總之，使用常識。嘗試測試報告的呈現可能沒有意義。您可以手動測試案例，測試人員必須手動完成這些測試案例，或者親自檢查報告。

你可能也想看看「How Much Unit Test Coverage Do You Need? - The Testivus Answer」

Answer 3

我問自己，在這些情況下的問題是「我怎麼知道我這樣做是正確」？

我在自己的職業生涯中寫了很多代碼，幾乎所有代碼都沒有在第一次運行。幾乎每次我回過頭來改變代碼以進行重構，功能改變，性能或錯誤修復時，我都會再次破壞它。 TDD保護我免於自我（謝天謝地！）。

在生成的代碼的情況下，我不覺得有必要測試代碼。也就是說，我相信代碼生成器。但是，我確實想要將我的輸入測試到代碼生成器。具體怎麼做取決於具體情況，但一般的做法是問自己，我可能會犯錯，然後找出如何確認我是否正確。

也許我寫了一個自動化測試。也許我會手動檢查某些東西，但這非常危險。也許別的東西。這取決於實際情況。

Answer 4

某些應用程序或框架只是繼承了單元測試不友好的狀態，實際上並沒有太多可以做的事情。我傾向於完全避免這樣的框架，但如果絕對不得不處理這些問題，將所有邏輯抽取到可測試的庫中會很有幫助，而只在框架中留下聲明性代碼。

Answer 5

爲了把一個稍微不同的自旋馬克塞曼和Jay Bazuzi答案：

你的問題是報告前端產生的輸出，你不能輕易的「驗證」部分檢查數據格式的試驗。

來處理這類問題的方法是：

1. 有一些非常高層次的集成測試表面上確認您的後端代碼掛鉤正確到您的前端代碼。我通常稱這些測試爲「煙霧測試」，如「如果我打開電源並且它抽菸，這很糟糕」。

2. 查找測試後端報告代碼的其他方法。既可以測試中間輸出數據結構，也可以實現更易於測試的備用輸出前端，HTML，純文本等等。

這與測試網絡應用程序的常見問題類似：無法自動測試「網頁看起來不錯」。但是，測試頁面數據中的詞語和數字是否正確（使用機械化和頁面刮除器等程序化瀏覽器）並且如果頁面嚴重依賴時有幾個表面功能測試（使用Selenium或Windmill）就足夠了在Javascript上。

Answer 6

考慮從PDF中提取文本並檢查它。但是，這不會給你格式。如果圖表在pdf中，某些pdf抽取程序可以抽出圖像。

Answer 7

面對這種情況，我嘗試了兩種方法。

1. The Golden Master approach。生成報告一次，自己檢查一下，然後將其保存爲「黃金大師」。編寫一個自動化測試，將其輸出與黃金大師進行比較，並在兩者不同時失敗。

2. 自動完成數據的測試，但手動檢查格式。我自動檢查生成報告數據的模塊，但爲了檢查報告格式，我生成了具有硬編碼值的報告並手動檢查報告。

我強烈建議您不生成完整的報告只是爲了檢查報表上的數據的正確性。當你想檢查報告（而不是數據），然後生成報告;當你想檢查數據（而不是格式）時，只能生成數據。