JUnit 假定測試的所有方面都是開發人員的地盤，而集成測試框架（FIT）在編寫需求的業務客戶和實現需求的開發人員之間做了協作方面的試驗。這是否意味著 FIT 和 JUnit 是競爭關系呢？不是！代碼質量完美主義者 Andrew Glover 介紹了如何把 FIT 和 JUnit 兩者好的地方結合在一起，實現更好的團隊工作和有效的端到端測試。
在軟件開發的生命周期中，每個人都對質量負有責任。理想情況下，開發人員在開發周期中，用像 Junit 和 TestNG 這樣的測試工具保證早期質量，而質量保證團隊用功能性系統測試在周期末端跟進，使用像 Selenium 這樣的工具。但是即使擁有的質量保證，有些應用程序在交付的時候仍然被認為是質量低下的。為什么呢？因為它們并沒有做它們應當做的事。
在客戶、（編寫應用程序需求的）業務部門和（實現需求的）開發團隊之間的溝通錯誤，通常是摩擦的原因，有時還是開發項目徹底失敗的常見原因。幸運的是，存在一些方法可以幫助需求作者和實現者之間盡早 溝通。
下載 FIT
集成測試框架（FIT）初是由 Ward Cunningham 創建的，他是 wiki 的發明人。請訪問 Cunningham 的 Web 站點了解關于 FIT 的更多知識并 免費下載它。
FIT 化的解決方案
集成測試框架 （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 的力量在于編碼過程中的單元測試，而 FIT 是更高層次的測試工具，用來判斷規劃的需求實現的正確性。
例如，雖然 JUnit 擅長驗證兩個 Money 對象的合計與它們的兩個值的合計相同，但 FIT 可以驗證總的訂單價格是其中商品的價格減去任何相關折扣之后的合計。區別雖然細微，但的確重大！在 JUnit 示例中，要處理具體的對象（或者需求的實現），但是使用 FIT 時要處理的是高級的業務過程。
