JUnit 假定測試的所有方面都是開發人員的地盤，而集成測試框架（FIT）在編寫需求的業務客戶和實現需求的開發人員之間做了協作方面的試驗。這是否意味著 FIT 和 JUnit 是競爭關系呢？絕對不是！代碼質量完美主義者 Andrew Glover 介紹了如何把 FIT 和 JUnit 兩者最好的地方結合在一起，實現更好的團隊工作和有效的端到端測試。
在軟件開發的生命周期中，每個人都對質量負有責任。理想情況下，開發人員在開發周期中，用像 Junit 和 TestNG 這樣的測試工具保證早期質量，而質量保證團隊用功能性系統測試在周期末端跟進，使用像 Selenium 這樣的工具。但是即使擁有優秀的質量保證，有些應用程序在交付的時候仍然被認為是質量低下的。為什么呢？因為它們并沒有做它們應當做的事。
在客戶、（編寫應用程序需求的）業務部門和（實現需求的）開發團隊之間的溝通錯誤，通常是摩擦的原因，有時還是開發項目徹底失敗的常見原因。幸運的是，存在一些方法可以幫助需求作者和實現者之間盡早 溝通。
 |
|
集成測試框架 （FIT）是一個測試平臺，可以幫助需求編寫人員和把需求變成可執行代碼的人員之間的溝通。使用 FIT，需求被做成表格模型，充當開發人員編寫的測試的數據模型。表格本身充當輸入和測試的預期輸出。
圖 1 顯示了用 FIT 創建的結構化模型。第一行是測試名稱，下一行的三列是與輸入（value1 和 value2）和預期結果（trend()）有關的標題。
圖 1. 用 FIT 創建的結構化模型
好消息是，對于編程沒有經驗的人也能編寫這個表格。FIT 的設計目的就是讓消費者或業務團隊在開發周期中，盡早與實現他們想法的開發人員協作。創建應用程序需求的簡單表格式模型，可以讓每個人清楚地看出代碼和需求是否是一致的。
清單 1 是與圖 1 的數據模型對應的 FIT 代碼。不要太多地擔心細節 —— 只要注意代碼有多么簡單，而且代碼中沒有包含驗證邏輯（例如，斷言等）�？赡苓�會注意到一些與表 1 中的內容匹配的變量和方法名稱；關于這方面的內容后面介紹。
清單 1. 根據 FIT 模型編寫的代碼
package test.com.acme.fit.impl;
import com.acme.sedlp.trend.Trender;
import fit.ColumnFixture;
public class TrendIndicator extends ColumnFixture {
public double value1;
public double value2;
public String trend(){
return Trender.determineTrend(value1, value2).getName();
}
}
|
清單 1 中的代碼由研究上面表格并插入適當代碼的開發人員編寫。最后，把所有東西合在一起，FIT 框架讀取表 1 的數據，調用對應的代碼，并確定結果。
FIT 的優美之處在于，它讓組織的消費者或業務端能夠盡早參與測試過程（例如，在開發期間）。JUnit 的力量在于編碼過程中的單元測試，而 FIT 是更高層次的測試工具，用來判斷規劃的需求實現的正確性。
例如，雖然 JUnit 擅長驗證兩個 Money 對象的合計與它們的兩個值的合計相同，但 FIT 可以驗證總的訂單價格是其中商品的價格減去任何相關折扣之后的合計。區別雖然細微，但的確重大！在 JUnit 示例中，要處理具體的對象（或者需求的實現），但是使用 FIT 時要處理的是高級的業務過程。
這很有意義，因為編寫需求的人通常不太考慮 Money 對象 —— 實際上，他們可能根本不知道這類東西的存在！但是，他們確實要考慮，當商品被添加到訂單時，總的訂單價格應當是商品的價格減去所有折扣。
FIT 和 JUnit 之間絕不是競爭關系，它們是保證代碼質量的好搭檔，正如在后面的 案例研究 中將要看到的。
表格是 FIT 的核心。有幾種不同類型的表格（用于不同的業務場景），FIT 用戶可以用不同的格式編寫表格。用 HTML 編寫表格甚至用 Microsoft Excel 編寫都是可以的，如圖 2 所示：
圖 2. 用 Microsoft Excel 編寫的表格
也有可能用 Microsoft Word 這樣的工具編寫表格，然后用 HTML 格式保存，如圖 3 所示：
圖 3. 用 Microsoft Word 編寫的表格
開發人員編寫的用來執行表格數據的代碼叫作裝備（fixture）。要創建一個裝備類型，必須擴展對應的 FIT 裝備，它映射到對應的表。如前所述，不同類型的表映射到不同的業務場景。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
