使用Fitness與自動集成測試相比有什麼優勢？

Question

使用Fitness與自動集成測試相比有什麼優勢？在努力提供經過充分測試的解決方案時，我正努力地看到Fitness 在哪裏適合。當然，如果開發者有單元並集成測試他們的代碼，那麼這應該足夠了。爲什麼需要重複我們的集成測試工作？

Answer 1

測試用例在敏捷環境主要有四種主要類型：

1）自動化的單元測試（例如，使用J-單元）;

2）自動功能驗證測試（例如使用Fitnesse）; 3）自動功能/迴歸測試（例如使用Selenium或QuickTestPro）;

4）手動測試。

對於類型1-3，當然有指定的自動化測試用例。對於類型4，測試用例往往是邏輯（或高級）測試用例，這就要求測試人員具備更高水平的技能和領域知識。而且，大量的基於經驗的測試（例如探索性測試，缺陷分類測試等）往往會發生。

見紅細胞博客here：

Answer 2

健身應該讓業務分析師更容易擁有和運行測試。開發人員創建燈具;業務分析師提供數據並確認測試通過。

根據我的經驗，業務分析師既沒有背景也沒有興趣去做這樣的事情。

健身測試更像集成測試。它們可能涉及多個組件。單元測試應由開發人員在單個組件上完成。因此名稱爲「單位」。

我更喜歡單元測試。

Answer 3

使用健身的主要原因是如果你打算讓非技術人員編寫測試。舉例來說，假設我們必須支持大量不同的佣金支付方式。非技術人員可以製作電子表格，顯示一個小夥子賺取一定數量的麪糰，詢問系統應該得到多少佣金，然後聲稱計算是正確的。

就我個人而言，我發現FIT比它的價值更麻煩。我認爲，如果製造商認真對待並設置了一些工具進行設置和配置，它可能是一個非常有吸引力的工具。

但是最主要的是隻有在確定要有很多業務規則類型的東西來驗證BA甚至客戶可以直接參與時才使用它。這並不是要斷言軌道常數是正確計算。

Answer 4

問題隱含着錯誤的二分法; FitNesse 是的一款自動化集成測試解決方案。這只是測試（旨在）被創建爲wiki頁面中的標記。

我目前正在使用它作爲我的集成測試解決方案;我使用the command line運行所有集成測試。測試也可以通過JUnit或REST API運行（這將需要運行FitNesse服務器）。

As Rob mentions in their answer，它不是非常容易設置和配置，我沒有覺得它太難。我反駁羅布的說法：「這不是斷言軌道常數正在被正確計算。」;事實上，它完全適用於此。

我遇到過這個問題，因爲我正在尋找使用的人的評估，或者曾使用Fit或FitNesse的人對單元進行測試。我想到這個想法的原因是，作爲一名開發人員，我發現以FitNesse wiki頁面的形式理解一組測試比代碼文件更容易。

下面是來自我的一個項目的測試頁面的示例。這些測試是集成測試，但我想不出爲什麼這對於單元測試也不適用。測試的代碼沒有什麼特別之處，可以防止單元測試。