驗收測試驅動開發的服務與幾個客戶端

我有一個問題有關驗收測試驅動開發（ATDD）。我的應用程序是作爲REST服務開發的，可能有幾個客戶端 - 網站，手機，桌面。 ATDD的概念說，我應該通過端到端測試來啓動每項功能。由於我的服務可能有多個客戶端應用程序（結束）提供相同的用例，因此在編寫驗收測試時應使用什麼方法？驗收測試是否應將REST服務或客戶端應用程序的直接請求作爲輸入？或兩者？我明白，如果我的驗收測試是從REST請求開始的，那麼我省略了客戶端部分，這肯定是不好的。如果這些都是從客戶端開始的，我會爲每個客戶重複基本相同的功能測試。我需要找到一種處在這些邊緣中間的方法。驗收測試驅動開發的服務與幾個客戶端

來源

2013-03-27 Markus

「ATDD概念，說我應該開始每一項功能與終端到終端的測試」。我不同意這是必需的。你的來源是什麼？ – 2013-03-30 02:34:25

在練習ATDD時，我認爲驗收測試只是另一個用戶界面。據說，我會在業務層的UI下進行測試。假設我有一個功能：

Given I have an addend of 5 
and an augend of 3 
When I calculate the sum 
Then I should receive 8

執行此測試時，我的接縫將位於業務層。假設我的測試看起來像一個Java /彈簧類型的應用程序：

@Given("I have an addend of (\\d+)") 
public void addend(int addend) { this.addend = addend; } 

@Given("I have an augend of (\\d+)") 
public void augend(int augend) { this.augend = augend; } 

@When("I calculate the sum") 
public void calculate() { 
    calculator = applicationContext.getBean(ScientificCalculator.class); 
    actualResult = calculator.sum(addend, augend); 
} 

@Then("I should receive (\\d+)") 
public void verifyResult(int result) { assertEquals(result, this.actualResult); }

一旦我開發的ScientificCalculator和所有的測試場景通過背後的商業邏輯，我知道，應用程序的功能，它需要從功能角度來看。因爲這完全繞過了UI，所以不需要爲每個UI重複測試。用戶界面現在變得完全沒有業務規則（一件好事），你可以把XML，JSON，HTML，你想要的任何UI放在前面。假設我們使用的是Spring MVC，控制器就像下面這樣簡單：

@GET("calculate/sum/{addend}/{augend}") 
public void addSomeNumbers(String addend, String augend) { 
    result = calculator.sum(Integer.parseInt(addend), Integer.parseInt(augend)); 
    // Render the view with the result. 
}

我會測試UI嗎？大概。但還不夠徹底，因爲現有測試涵蓋了主要業務規則，而且一般來說，UI錯誤的風險要低於誤解或錯誤實施的業務邏輯，因此風險要低一些，並且易於修復。

希望有幫助！

布蘭登

來源

2013-03-28 00:17:53 bcarlso

由於@bcarlso建議，可以在業務規則方面編寫驗收測試，所以他們不是具體到某個特定的平臺。

使用這些規範來測試每個平臺的端到端情況當然是可能的，許多組織都這樣做。但是你可能會以一個非常大的，速度很慢的測試套件結束，這很難維護。

黃瓜和類似工具ATDD並沒有要求您測試端到端。您可以使用它們來驗證在某個類中作爲單一方法聚焦的某些內容中的行爲。

重點關注您的努力，撰寫良好的單元測試，以便在集成之前捕獲絕大多數缺陷。不要依靠自動化的驗收測試來作爲一個糟糕的開發過程的質量保證。使用少量的高級端到端測試來測試通過應用程序的主要成功路徑。

這裏有一個權衡：一些集成相關的問題可能通過網絡。執行根本原因分析並嘗試確定未來如何避免類似缺陷。在適當的級別添加其他測試。只是不要讓你的項目淹沒在自己的測試套件中。

來源

2013-03-30 02:47:37

驗收測試驅動開發的服務與幾個客戶端

回答

相關問題