問題
我們已經應用了Command模式來表現一個測試用例。Command依賴於一個單獨的像execute()這樣的方法（在TestCase中稱爲run()）來對其進行調用。這樣允許我們能夠通過相同的接口來調用一個command的不同實現。
如果實現一個測試用例，就必須實現繼承Testcase，然後實現run方法，實際是testRun，測試人員就把所有的測試用例都繼承相同的類，這樣的結果就會造成產生出大量的子類，使系統的測試維護相當困難，並且setUp和tearDown僅爲這個testRun服務，其他的測試也必須完成相應的代碼，從而增加了開發人員的工作量，怎樣解決這個問題？
爲了避免類的急劇擴散，試想一個給定的測試用例類可以實現許多不同的方法，每一個方法都有一個描述性的名稱，如testGetMessage或testSetMessage。這樣測試用例並不符合簡單的command接口。因此又會帶來另外一個問題就是，使所有測試方法從測試調用者的角度（JUnit框架）上看都是相同的。怎樣解決這個接口不匹配問題？
思考設計模式的適用性，Adapter（適配器）模式便映入腦海。Adapter具有以下意圖“將一個類的接口轉換成客戶希望的另外一個接口”。這聽起來非常適合。把具有一定規則的描述性方法如testGetMessage，轉化爲JUnit框架所期望的Command（TestCase的run）從而方便框架執行測試。Adapter模式又分爲類適配器和對象適配器。類適配器是靜態的實現在這裏不適合使用，於是使用了對象適配器。
適配器模式的構成：
1、Target 系統所期望的目標接口
2、 Adaptee 現有需要適配的接口
3、 Adapter 適配器角色，把源接口轉化成目標接口
模式的記憶方式：
假如我們家的檯燈的插頭是2相的，但是我們牆壁上的電源插座是3相的，那我們如何用呢？？？可以去買一個插排，插排接電源的是3孔的，插排上有很多插孔是2孔的，那麼插排起到的作用就是橋樑，起轉換的作用，在這裏就是適配器模式中的適配器。
適配器模式的代碼實現：
Target: //檯燈插頭
public interface Target {
public void method1();
}
Adapter: //插排
public class Adapter implements Target {
private Adaptee adaptee;
public Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
public void method1() {
adaptee.method2();
}
}
Adaptee: //牆壁上的電源
public class Adaptee {
public void method2() {
System.out.println("method2");
}
}
Client:
public class Client {
public static void main(String[] args) {
Target target = new Adapter(new Adaptee());
target.method1();
}
}
在實現對象的適配時，首先在TestCase中定義測試方法的命名規則必須是public void testXXXXX()這樣我們解析方法的名稱，如果符合規則認爲是測試方法，然後使用Adapter模式把這些方法，適配成Command的runTest方法。在實現時使用了java的反射技術，這樣便可很容易實現動態適配。代碼如下
protected void runTest() throws Throwable {
//使用名稱獲得對象的方法，如testGetMessage，然後動態調用，適配成runTest方法
Method runMethod= getClass().getMethod(fName, null);
runMethod.invoke(this, new Class[0]);
}在這裏目標接口Target和適配器Adapter變成了同一個類,TestCase，而測試用例，作爲Adaptee
效果
我們來考慮經過使用Adapter模式後給系統的架構帶來了那些效果：
1、使用Adapter模式簡化測試用例的開發，通過按照方法命名的規範來開發測試用例，不需要進行大量的類繼承，提高代碼的複用，減輕測試人員的工作量
2、使用Adapter可以重新定義Adaptee的部分行爲，如增強異常處理等