我被要求改變一些對於我們工作的系統來說是核心的類。所討論的類每個需要5-10個不同的相關對象，它們本身需要類似的對象。在我的系統中嘲笑/測試一個核心對象
數據也從幾個數據源中提取，並且項目使用EJB2，所以在測試時，我運行的時候沒有容器來拉入我需要的依賴關係！
我開始因此任務而不知所措。我已經嘗試過使用JUnit和Easymock進行單元測試，但只要我嘲笑或存根一件事情，就會發現它需要更多。一切似乎都非常緊密地聯繫在一起，以便我可以使用存根達到3或4個級別，以防止出現NullPointerException。
通常這種類型的任務，我會隨着我一起進行更改和測試。但最短的構建週期約爲10分鐘，而且我喜歡在執行之間進行非常短的迭代編碼（可能是因爲我對編寫無瑕代碼的能力不太自信）。
任何人都知道一個好的策略/工作流程來擺脫這個泥潭？
正如你所建議的，這聽起來像是你的主要問題是你正在使用的API過於緊密。如果您有修改API的能力，那麼隱藏接口後面的即時依賴關係會非常有幫助，這樣您就可以直接依賴關係切斷依賴關係圖。
如果這不可行，自動嘲弄容器可能會有所幫助。這基本上是一個容器，它可以自動計算出如何爲嵌套抽象返回一個具有良好默認行爲的模擬。當我處理.NET框架時，我不能推薦任何用於Java的東西。
如果您想了解單元測試模式和最佳做法，我只能推薦xUnit Test Patterns。
對於解耦緊密耦合代碼的策略，我推薦Working Effectively with Legacy Code。
我試圖做的第一件事就是縮短構建週期。也許增加選項來只構建和測試當前正在開發的組件。
接下來，我將介紹通過引入接口來解耦每個組件之間的某些依賴關係。我也希望使用依賴注入最有可能將耦合移出。如果我不能移動到DI，那麼我會在兩個服務器上使用服務定位器（或您的服務定位器）和一個注射器。
該項目使用EJB2，所以當測試時，我運行沒有容器來拉我需要的依賴關係！
這是不是意味着與？我會考慮儘可能多地移植到POJO中，以便可以在不需要知道任何EJB-y的情況下進行測試。
如果你的項目可以用Java 1.5進行編譯，你可以看看JMock？用這個框架的2. *版本可以很快地把事情弄糟。
1. *版本將與1.3 + Java編譯器一起工作，但嘲笑更加冗長，所以我不會推薦它。
至於戰略，我對你的建議是擁抱界面。即使您有給定接口的單個實現，也要創建一個接口。它們可以很容易地被嘲笑，並且在測試代碼時可以讓你更好地解耦。