如何確保我正在測試所有內容，我擁有舊代碼的所有功能和特性？

Question

我們正在運行一個非常大的網站，我們有一些關鍵的遺留代碼，我們想要很好地覆蓋。

同時，我們希望報告我們目前支持和涵蓋的功能。而且我們也希望確保我們確實涵蓋了每個可能的角落案例。一些代碼路徑非常重要，甚至在達到100％的覆蓋率後也需要更多的測試。

由於我們已經在使用rspec和rspec有「功能」和「場景」關鍵字，我們試圖使用rspec製作一個列表而不是去黃瓜，但我認爲這個問題可以應用於任何測試工具。

我們希望是這樣的：

feature "each advertisement will be shown a specified % of impressions" 
    scenario "As ..." 

此功能從視圖管理器的最低點，但在代碼巨大。它涉及後端工具，定期任務，模型中的邏輯以及後端和前端的視圖。 我們試圖把它像這樣：

feature "each creative will be shown a specified % of impressions" 
    context "configuration" 
    context "display" 
     scenario "..." 
    context "models" 
     it "should ..." 
    context "frontend" 
    context "display" 
     scenario "..." 
    context "models" 
     it "should ..." 

配置發生在另一個工具，顯示將包含集成測試和模型將包含單元測試。

我重複自己的想法是確保該功能真正完成（包括構建配置工具）並經過100％測試。

但是看這個文件，它不是集成，也不是單元測試，甚至不屬於任何特定的項目。 當然應該有更好的方式來管理這個。

任何經驗，資源，想法，你可以分享，以指導我們？

Answer 1

您描述的場景是BDD如此受歡迎的一個重要原因。它迫使你以易於測試的方式編寫代碼。話雖如此，你顯然不會回頭重寫整個遺留應用程序。還有，你應該考慮的，雖然幾件事情：

• 當你通過應用程序的每個部分，你應該問自己「它會更難重構比寫這個測試？」。有時在編寫測試之前重構是無法避免的。
• 測試不是100％覆蓋率，而是100％的信心。正如你所提到的，即使你有100％的覆蓋率，你也計劃編寫更多的測試。這是因爲你要信心。一旦你對一段代碼有信心，繼續前進。你可以隨時回來。
• 從我的經驗來看，Cucumber更容易覆蓋大部分應用程序的測試。我認爲這樣做的原因是用簡單的英文寫出測試會讓你想到你不會有的東西。它還使您可以專注於行爲而不是代碼，並可以使重構成爲一項不那麼艱鉅的任務。
• 如果您從未再次觸摸該代碼，那麼您無法從現有代碼中添加測試。首先測試您想要進行更改（即重構）的代碼。

我也推薦書Rails Test Prescriptions，特別是最後一章稱爲「測試遺留應用程序」。