最近在做公司的单元测试框架，本来感觉已经初具规模，可以开始正常的使用了，因为我写了40多个各种类型的测试用例都可以正常工作，另外一个组的同事开始写了一个，他说还是挑的一个最简单的，结果报了一堆的异常，呵呵，其实他是测试Message Driven Bean，代码里面要调用很多其它的东西，出了几个问题，一个是他要使用的一个Entity Bean的finder是我写的表达式不支持的，我只能把那个finder实现掉，然后就是代码中使用了一个Topic，而且不是我们的Server端代码使用的，没有对应的Message Driven Bean处理（框架只能自动发布有对应的Message Driven Bean的Queue或者Topic），这个问题忽略不计了，因为那个Message本来就不需要处理，然后就是另外一个finder方法，我的表达式是支持的，但是死活找不到，结果发现是那个Entity Bean的xdoclet的配置比较特殊，一般的Home接口都是Remote接口的名字加Home，结果那个Bean是加BeanHome，而Aspect的匹配表达式是默认的格式，没有办法，修改我的表达式了，谁让那个Home接口的名字是可配置的呢。
另外两个问题还没有搞定，一个是Stateless Session Bean的remove方法，不知道要做什么，我现在处理了Entity Bean的remove，调用那个的时候会从数据库中删除对应的记录，但是Stateless Session Bean的remove应该做什么呢？
一个是获得Topic，我们的那个Locator接口里面定义了获得各种Bean以及Queue的接口方法，但是没有定义获得Topic的方法，所以代码中都是使用：
Context jndiContext = new InitialContext();
topic = (Topic) jndiContext.lookup(serverDataSendTopicName);
这个lookup的过程框架拦截不到。

本来今天已经完成了框架的大部分功能，写的一些测试用例都可以成功执行，但是自动发布是放在BaseTestCase里面的，感觉不好，就重构了一下，扩展了InitialContext类，覆盖了lookup方法（参数为字符串的那个，我们的代码中都是使用的这个），这样代码看起来更好一些的。另外我们的系统里面使用到了一些类似的机制，我为了产品可以进行单元测试还对一些Factory类进行了简单的修改，让他们返回我为了单元测试而写的实现类。如果使用这个扩展的InitialContext类，应该不需要做那些修改了，试了下，发现不行，因为产品的代码好像和Jboss的某些特性进行绑定了，先做简单的重构，以后再研究产品到底使用了JBoss的哪些特性，能否搞定。
代码如下：
阅读全文

前段时间大致介绍了下这个测试框架，目前还没有完全完成，这里先慢慢介绍下框架得构成，这个是第一篇。

其实MockEJB提供的功能还是比较简单的，做单元测试需要我们自己写代码发布Bean，例如发布一个Session Bean：
            SessionBeanDescriptor sampleServiceDescriptor =
                new SessionBeanDescriptor( SampleService.JNDI_NAME,
                SampleServiceHome.class, SampleService.class, new SampleServiceBean() );
             mockContainer.deploy( sampleServiceDescriptor );

其实每个EJB工程都应该有现成的EJB配置文件（ejb-jar.xml、jboss.xml、jbosscmp-jdbc.xml），因此这个发布工作应该可以自动完成，思路就是自己读取那些配置文件获得EJB的配置信息。
然后就是要修改lookup的过程，由于我们的工程提供一个共通的接口来进行lookup，所以问题就演变为实现一个那个接口。对于其它的项目，应该是类似的，如果是直接使用Context的lookup，那么对于MockEJB而言就是扩展MockContext，覆盖lookup方法，先查找，找到目标就返回，没有的话尝试根据读取的EJB配置信息自动发布需要的EJB。这样，我们就在单元测试中可以直接获取EJB，而不用再进行发布了。