我被要求改变一些对于我们工作的系统来说是核心的类。所讨论的类每个需要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编译器一起工作，但嘲笑更加冗长，所以我不会推荐它。
至于战略，我对你的建议是拥抱界面。即使您有给定接口的单个实现，也要创建一个接口。它们可以很容易地被嘲笑，并且在测试代码时可以让你更好地解耦。