单元测试如何应对以下2个简单的情况

由调用那个方法的对象实例化它，再作为参数传给那个方法啊，这有什么问题吗？还是我理解错你的意思了？
－－－方法内部如何实现是方法自己的内部逻辑问题，而调用方法的对象是不需要知道所调用的方法内部是需要什么其它对象的，不是吗？所以，我认为你不可能为了调用一个方法，而为这个方法生成它所需要的其它对象，然后再传进去。

懂了IOC就明白了。
玩玩picocontainer或spring吧

http://gigix.blogdriver.com/diary/gigix/inc/DependencyInjection.pdf

mockup的前提是design by interface。
如果不想用IoC, 不想用成员变量，参数等传递具体实现类，那么还可以用继承来做unit test。

class MyClass{
public method_1(){

OtherInterface oc = getOtherInterface();
......
}

OtherInterface getOtherInterface(){
   return new OtherClass();
}
}


---------for unit test

class MyClassMockup extends MyClass{
public method_1(){

OtherInterface oc = getOtherInterface();
......
}

OtherInterface getOtherInterface(){
   return new OtherClassMockup();
}
}

楼主总是在讨论如何解决这个问题，却始终不愿意思考为什么会有这个问题。
其实楼上有个朋友说得很好“解决的办法就是把它们重构成具有良好可测性的代码。这也是一个设计的过程。优质的代码必然是具备良好可测性的。”。首先可测试性的一个重要基础就是你的结构要清晰。更简单地说，也就是单个测试组件是可插拔的。
    如果楼主熟悉UML，可以发现从UML中的对象关系中关联是适合进行结构拆分的。
    楼上许多网友提的方案，也就是将局部变量转变为全局变量，对象间的关系变化了，由依赖转变为关联，这样，耦合度提高了，内聚降低了。这样就是说楼上担心是否有影响的原因。但是，这样的变化，就可以将两个本身内聚的对象进行耦合的拆分，这样，也就是将两个对象进行了测试的独立。
    其实楼主首先要明白一个问题，什么是单元测试，单元测试是否只是测试一个类，一个方法。这是很多所谓的开发人员进行单元测试的误区。单元测试测试的对象是单元体，而所谓的单元体是一组内聚对象的集合，是无法拆分的共同体。简单说也就是也许有多个类组成。其实，另外有网友提出用MockEJB是更加正确的方式，为什么呢？因为在楼主的例子中，EJB环境只是你所测试类的一个组成部分，它们共同形成了单元体。而你的单元体是需要对这个单元进行测试（当然，这个单元体也大了些， ）。
    理清你的测试目标，适当调整你的测试结构，为测试而编写你的代码。