用模擬對象和aop來單位試驗struts的應用 外文翻譯稿.doc
約17頁DOC格式手機打開展開
用模擬對象和aop來單位試驗struts的應用 外文翻譯稿,用模擬對象和aop來單位試驗struts的應用aop如何補足oop來縮小整合間隙作者walter jia, javaworld.com, 11/09/06試驗驅動開發(fā)減少了發(fā)展努力的同時，提高了軟件質量。作為一個整體試驗策略的基礎， 單位試驗必須是全面的，設置簡單，執(zhí)行快速。但是，依賴于執(zhí)行環(huán)境和測試組外的代碼使我們達...
內(nèi)容介紹
此文檔由會員 wanli1988go 發(fā)布
用模擬對象和AOP來單位試驗Struts的應用
AOP如何補足OOP來縮小整合間隙
作者Walter Jia, JavaWorld.com, 11/09/06
試驗驅動開發(fā)減少了發(fā)展努力的同時，提高了軟件質量。作為一個整體試驗策略的基礎， 單位試驗必須是全面的，設置簡單，執(zhí)行快速。但是，依賴于執(zhí)行環(huán)境和測試組外的代碼使我們達到上述目標的能力復雜了。把應用程序部署在一個容器里顯然放慢了代碼和試驗周期。 此外，與其他組合作的要求通常會導致更加復雜的試驗設置和較慢的測試。
整合兩個流行測試框架，StrutsTestCase 和 EasyMock，和單元試驗Struts的應用會導致較簡單的試驗設置和較快速的試驗。 但是，這兩個框架留下缺口,阻止了理想的綜合。 在這篇文章中，我檢查了這個問題的面向對象的解決辦法和面向方面的解決辦法。通過簡化看似難以解決的問題，比較也顯示出面向方面的程序設計(AOP)是如何補足對象編程(OOP)的。
整合需要
重大的Struts的應用展示了執(zhí)行環(huán)境和種類依賴，因為Struts的行為是在Servlet的容器里完成的，典型地需要其他組來處理要求。 模擬對象測試方法,有助于消除不必要的附庸。Strutstestcase的試驗框架給一個模擬的Servlet容器的執(zhí)行提供了Mockstrutstestcase課堂，延伸了基礎 JUnit的試驗用例。它有利于科集裝箱檢驗，加快單位檢驗周期。Easymock，另一個測試框架，很容易地模擬動態(tài)的協(xié)作組。模擬以簡單執(zhí)行代替真正的組，加上邏輯論證來支持單位試驗。
顯然，把兩種框架結合起來是有利的，以便于Struts的應用能夠真正地獨立地進行試驗。理論上，你要根據(jù)下列步驟實施這個單位試驗：
1. 建立MockStrutsTestCase，以便于模擬Servlet的容器；
2. 模擬組，這一行為取決于使用Easymock；
Unit test Struts applications with mock objects and AOP
How AOP complements OOP to bridge the integration gap
By Walter Jia, JavaWorld.com, 11/09/06
Test-driven development improves software quality while reducing development efforts. As the foundation of an overall test strategy, unit tests must be comprehensive, easy to set up, and quick to execute. However, the dependency on the execution environment and on code outside the class under test complicates our ability to achieve these goals. Deploying the application in a container significantly slows down the code-and-test cycle. Furthermore, the need to collaborate with other classes usually leads to more complex test setups and slower test runs.
Integrating two popular test frameworks, StrutsTestCase and EasyMock, to unit-test Struts applications leads to easier test setups and faster test runs. However, these two frameworks leave a gap that prevents an ideal integration. In this article, I examine both an object-oriented solution and an aspect-oriented solution to this problem. The comparison also demonstrates how aspect-oriented programming (AOP) complements object-oriented programming (OOP) by simplifying the solution to a seemingly difficult problem.
AOP如何補足OOP來縮小整合間隙
作者Walter Jia, JavaWorld.com, 11/09/06
試驗驅動開發(fā)減少了發(fā)展努力的同時，提高了軟件質量。作為一個整體試驗策略的基礎， 單位試驗必須是全面的，設置簡單，執(zhí)行快速。但是，依賴于執(zhí)行環(huán)境和測試組外的代碼使我們達到上述目標的能力復雜了。把應用程序部署在一個容器里顯然放慢了代碼和試驗周期。 此外，與其他組合作的要求通常會導致更加復雜的試驗設置和較慢的測試。
整合兩個流行測試框架，StrutsTestCase 和 EasyMock，和單元試驗Struts的應用會導致較簡單的試驗設置和較快速的試驗。 但是，這兩個框架留下缺口,阻止了理想的綜合。 在這篇文章中，我檢查了這個問題的面向對象的解決辦法和面向方面的解決辦法。通過簡化看似難以解決的問題，比較也顯示出面向方面的程序設計(AOP)是如何補足對象編程(OOP)的。
整合需要
重大的Struts的應用展示了執(zhí)行環(huán)境和種類依賴，因為Struts的行為是在Servlet的容器里完成的，典型地需要其他組來處理要求。 模擬對象測試方法,有助于消除不必要的附庸。Strutstestcase的試驗框架給一個模擬的Servlet容器的執(zhí)行提供了Mockstrutstestcase課堂，延伸了基礎 JUnit的試驗用例。它有利于科集裝箱檢驗，加快單位檢驗周期。Easymock，另一個測試框架，很容易地模擬動態(tài)的協(xié)作組。模擬以簡單執(zhí)行代替真正的組，加上邏輯論證來支持單位試驗。
顯然，把兩種框架結合起來是有利的，以便于Struts的應用能夠真正地獨立地進行試驗。理論上，你要根據(jù)下列步驟實施這個單位試驗：
1. 建立MockStrutsTestCase，以便于模擬Servlet的容器；
2. 模擬組，這一行為取決于使用Easymock；
Unit test Struts applications with mock objects and AOP
How AOP complements OOP to bridge the integration gap
By Walter Jia, JavaWorld.com, 11/09/06
Test-driven development improves software quality while reducing development efforts. As the foundation of an overall test strategy, unit tests must be comprehensive, easy to set up, and quick to execute. However, the dependency on the execution environment and on code outside the class under test complicates our ability to achieve these goals. Deploying the application in a container significantly slows down the code-and-test cycle. Furthermore, the need to collaborate with other classes usually leads to more complex test setups and slower test runs.
Integrating two popular test frameworks, StrutsTestCase and EasyMock, to unit-test Struts applications leads to easier test setups and faster test runs. However, these two frameworks leave a gap that prevents an ideal integration. In this article, I examine both an object-oriented solution and an aspect-oriented solution to this problem. The comparison also demonstrates how aspect-oriented programming (AOP) complements object-oriented programming (OOP) by simplifying the solution to a seemingly difficult problem.
