Series of Effective Mockito articles有在OpenEJB的一些支持,你可能会发现与嘲弄的组合使用。
作为EJB 3.0 Embedded EJBContainer API的替代方案,您可以简单地在代码中构建应用程序。
import junit.framework.TestCase;
import org.apache.openejb.jee.EjbJar;
import org.apache.openejb.jee.StatelessBean;
import org.apache.openejb.junit.ApplicationComposer;
import org.apache.openejb.junit.Module;
import org.junit.Test;
import org.junit.runner.RunWith;
import javax.ejb.EJB;
@RunWith(ApplicationComposer.class)
public class ProcessorBeanTest extends TestCase {
@EJB
private ProcessorBean processorBean;
@Module
public EjbJar beans() {
EjbJar ejbJar = new EjbJar();
ejbJar.addEnterpriseBean(new StatelessBean(ProcessorBean.class));
ejbJar.addEnterpriseBean(new StatelessBean(MockDao.class));
return ejbJar;
}
@Test
public void test() throws Exception {
// use your processorBean
}
}
这里我们看到一个由ApplicationComposer
运行的测试用例。它是JUnit测试运行器的简单包装,它可以查找可用于定义应用程序的@Module
方法。
这实际上是OpenEJB多年来做了所有内部测试的结果,也是我们决定在前几个版本(自3.1.3开始)之后开放的内容。它超越了功能强大且速度极快的特性,因为它可以省去类路径扫描和一些较重的部署。
Maven的依赖性看起来可能是这样:
<dependencies>
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0-3-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
<!--
The <scope>test</scope> guarantees that none of your runtime
code is dependent on any OpenEJB classes.
-->
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>openejb-core</artifactId>
<version>4.0.0-beta-1</version>
<scope>test</scope>
</dependency>
</dependencies>
非常有趣的功能。不知道*关于Open EJB的信息 - 感谢分享! – 2012-01-03 23:06:54
@David Blevins在这种情况下,MockDao.class是一个开发者实现的DAO的假吗? – Bala 2012-01-11 12:13:58
@Bala确实如此。因此,从理论上讲,MockDao可以抛出一个异常来伪造一个持久性失败或其他东西,或者硬连接返回一个特定的实体等。静态内部类可以正常工作,所以MockDao可以在测试用例中正确定义。大多数在OpenEJB中的单元测试都倾向于有一堆静态的内部类“测试”bean。测试豆(aka mock beans)往往很小,很高兴将它们放在一起。 – 2012-01-11 17:05:52