解惑

解己之惑,解人之惑

标签:框架 (第1页共2页)

测试框架

最近在做C#版的测试框架,目的其实是让QA不用写代码就可以测试API,QA需要写一些XML,然后交给这个测试框架运行。

设计其实比较直接,把功能测试中的一些概念抽取出来包装下就可以了,XML要人可读可写,然后能够直接转换为对应的类,免去解析的过程最好。

我提取出来的主要概念如下:

  • Library,对应的其实就是DLL,就像java中的jar一样,可以从指定的路径load,也可以从系统的GAC(windows特定的东西)里面load。
  • Instance,其实本来想叫Object,因为是关键字,只能取这个比较紧似的名字,另外,声明的也确实是对象的instance而不是对象定义。
    • List,集合类型,可以当成List或者Array用。
    • WebService,这个是Instance的子类可能有点怪,但是框架的工作机制是生成WebService的Stub的对应的类,所以其实也是Instance,只是有一些额外的属性。
  • Operation,其实就是操作了,有很多子类型:
    • Method,就是方法调用了
    • Verify,主要是为了做结果验证,其实也是Method,只不过掩盖了实现,我用的就是NUit的实现。
    • Task,Operation的集合,本来想加一个Function的,但是感觉Function和Task功能完全一样。Task就相当于功能测试或者单元测试的一个方法。
    • Express,表达式,主要是为了支持简单的字符串连接和数学运算。
    • Field,获取或者设置Instance的field,我掩盖了C#中的Property和Field的区别,只提供Field,两种都可以访问。
    • Loop,其实也是Operation的集合,但是会把集合中的Operation重复执行很多次,用于性能测试或者批量调用,会生成一个索引值供Operation引用生成不同的值。
    • Indexer,访问集合类型中的某个指定下标的元素,主要是因为C#没有像Java一样提供Get(int index)方法,否则这个完全没有,直接用Method 就可以实现了。
    • Finder,主要是简化了从集合类型中查找某个元素,框架没有提供if/else这样的逻辑控制,只能提供这个变向的方式。
    • Wait,主要是提供Sleep以及异步调用支持,是Verify的子类型,可以每隔一段时间Verify一下,看看结果是不是match,然后有超时,超时就认为Veirfy失败。
  • Define,就是组件声明,里面包含的就是上面提到的那些东西。
  • Suite,就是Test Case了,包含Define列表和Task列表,以及Startup/Teardown

基本上已经涵盖测试中需要的大部分内容了。

一些额外的想法,Operation还是有很大扩展余地的,例如可以支持外部调用,例如调用一个命令行或者其它的程序。

保持开放的思想

今天突然发现自己原来对Ruby和RoR的抵触是完全没有道理的,因为自己理想中的Java开发框架和RoR的很多思想其实是相同的,可能是太喜欢Java,使用的时间也太长,任何对它可能构成威胁的东西都会有本能的反应了?
其实Java语言本来也是吸取其他语言的精华而创建出来的,每当有一种新的语言诞生的时候,也同时意味着它必定有什么优势,否则是很难被人接受并被广泛使用的,如果本着学习的精神,我们其实可以从这些新兴的语言身上学习和借鉴这些优点,并努力借用到Java的开发中,除了语言本身的限制,我们应该是可以借鉴很多。
我想如果一个掌握OO设计的高手去使用汇编或者C语言做开发,那么他在OO中学习到的一些东西肯定可以借用到这些语言中。

PS:Java世界一直没有出现我期望的框架,我自己也在尝试做一个,需要研究研究RoR了,很多规则或者思想可以借鉴过来

没落的Java社区

感觉原来的几个Java社区日益没落,当然这个和Java世界的消沉有很大关系,这两年已经看不到什么大的Java新闻了,特别是对于Java开发人员而言的大新闻,原来Spring带来的各种火热的讨论也已经沉寂下来,Java世界似乎已经毫无新意了,现有的任何Java开源产品或者组件所能够带来的开发效率的提升都无法和新的脚本语言匹敌(我想这也是为什么JavaEye会使用RoR重写的一个重要原因,同时也是Robin转向研究Ruby的重要原因),在可以预见的一段时间以内,都不太可能出现一颗真正的银弹。但是我对于Java并没有丧失信心,因为Java依然拥有广大的开发人员以及丰富的开源产品和组件,现在所缺少的是一个真正简单并且易用的快速开发框架,提供Java Web开发所必备的大部分功能,开发人员所需要关注的仅仅是创建数据库和业务逻辑代码(不需要开发常见的CRUD操作代码),当然开发人员也不需要太多的配置就能够让整个系统跑起来(不需要Spring的Bean配置、Struts的Action配置、Hibernate的配置)。
就我个人感觉,完成这样的一个框架并不是很难,困难在于Java世界应该引入更多的规则而不是可配置,最起码可配置是第二位的需求,但是Java世界的人似乎已经习惯了配置,习惯了对象间的关系是在运行时通过读取配置文件来确定,也习惯了通过读取配置文件来组装系统。
对于多人并行开发的系统而言,Java的强类型约束无疑对于代码的可维护性和可读性更加有利,但是基础设施的严重缺失使得代码的开发难度加大,代码的重复性也因此加大(对于一个简单功能,由于Java本身没有提供,只能自己写、寻找其它的开源组件或者公司自己的框架提供,但是很多新来的人不知道已经有那样的功能,即使知道也是拷贝一份代码稍加修改)。
我相信现在有很多人都有和我一样的想法,也有很多人在做,包括EasyJF(简易Java框架),问题是他们并不能真正的普及,他们的设计者和维护者并不能得到大部分人的认可,而像AppFuseSpringSideJdonFramework这样拼凑起来的快速开发框架也不能解决问题(还是需要大量的配置),我期望中的真正的Java快速开发框架是完全重写的基于规则的框架,不需要配置或者只需要极少的配置(例如数据库配置),具有强大的Model和View的转换能力,可以很容易的将POJO或者POJO集合转换为各种页面组件(表格、树),不需要POJO和数据库的映射配置,不需要写CRUD代码,URL请求自动映射到Action。。。。。。

KISS

记得最开始学习Java的时候就被它的KISS原则深深吸引了,因为那个时候正在为c++的各种语法而头疼。做了这么多年的Java开发,也感觉Java确实在语法和跨平台上符合它的这个原则,现在,Java的内容扩展越来越广,学习Java,使用好Java越来越需要对OO、设计模式、敏捷开发等深入理解并实践。
随着struts、spring和hibernate在国内的普及,越来越多的人得到提高,当然,我们也看到了以EasyJF为代表的国内开源力量的发展,在那些通用框架的基础上,他们期望能够进一步简化,实际上,我也在做这个工作,虽然我很欣赏spring和hibernate的灵活性,但是那么多的配置文件也是一个很头疼的事情,根据我自己的经验,很多应用没有必要进行配置,根据一定的规则就可以直接得到配置,为什么还要配置呢?即使是使用JDK5的新特性元数据进行简单配置我也感觉不是很必要,所以,我开始了我的大轮子计划,为自己定制一个最精简,最快速(性能和开发速度)的框架,在验证自己的设计能力的同时也可以强迫自己去学习别人的代码(但是不会全部照搬,也不会过度设计,需要的时候再重构),而且,这个框架我打算几乎完全自己构建,能够自己写的一定自己写,目前为止只使用了log4j和cglib这两个第三方的包,连连接池都是自己写的。在构造这个大轮子的过程中,我会把自己的心得体会写下来和大家交流。

完成轮子的第二个部分-缓存

昨天晚上花了一个多小时完成了我的大轮子的第二部分:缓存
今天中午利用休息时间写了测试用例,还算很顺利的,哈哈。

代码如下:
阅读全文

正式启动造大轮子计划

前几天说过想造一个大轮子,今天有点时间就开始写了一点代码。和上次不同的是,原来打算使用的OGNL打算放弃了,决定尽可能的使用JDK带的API和自己写的代码完成,尽可能少的使用第三方的代码,这样更好把握一些。进度可能会非常的慢,因为我会写完整的单元测试代码,并且因为公司加班的原因也没有多少时间投入这个,不过反正是我自己用,也不急。
今天的工作成果就是OGNL的简化版本:BeanAccessExpress。
语法比较简单,就是xxx.yyy[index].zzz[key]
只支持对象属性、数组、List和Map,长度不限。数组和List使用[index]访问,Map的元素使用[key]访问,key必须是字母开头的单词。
代码如下:
阅读全文

打算造一个大轮子

有感于这次单元测试框架的设计实现过程,决定慢慢的造一个大轮子:一个自己的web框架,初步计划是自己用,不考虑太通用,目的就是简单快捷的创建web应用,可以很方便的增加功能,基本上就是像ror一样简单快捷。
当然这个框架不会全部重写,肯定会基于现在的一些开源的组件搭建。但是肯定会排除spring和hibernate,因为这两个对于我而言是很大的轮子了。我需要的功能相对简单,我更喜欢基于规则而不是基于配置,很多东西其实没有必要配置,定义一套规则遵循就可以了。
初步拟定可能要使用到的一些组件是:

  • OGNL
  • prototype.js
  • overlib.js

总算是初步完成了EJB单元测试框架

经过一段时间的努力,我总算是初步完成了这个EJB单元测试框架,现在运行那些测试用例(183个,难易不等)只需要60秒左右,我挑选出来的一个做为样例的Session Bean的代码行覆盖率达到94%,而Branch覆盖率为100%。
明天计划说服其它的人使用这个框架辅助他们的开发,虽然这个是单元测试,但是因为不用启动JBoss也可以调试Session Bean和Action,我想使用它辅助开发也是个不错的主意(我们的JBoss启动需要至少2分钟,一般都是在3分钟以上)。另外一个进行辅助开发的原因是我们的时间很紧,原本计划在这个版本中要求新的功能必须有单元测试的要求可能也要取消了,那我辛辛苦苦完成的框架可能要拖到至少明年3月以后才可能被使用了,夜长梦多啊。
另外一个考虑就是他们写的测试用例越多,可能发现的问题也越多,也好帮助我更加完善这个框架。另外就是可能会要求我增加更多的功能辅助他们的验证工作。

艰难的过程

最近在做公司的单元测试框架,本来感觉已经初具规模,可以开始正常的使用了,因为我写了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的过程框架拦截不到。

MockEJB测试框架之自动发布EJB后续

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

更早的文章

© 2019 解惑

本主题由Anders Noren提供向上 ↑