2010年10月15日
#
摘要: 之前遇到几次现场故障，都是和class文件有关，比如版本不兼容造成Bad Version错误之类，需要检查class文件的编译版本信息。 今天无意中发现， jdk自带的javap 命令其实可以方便的搞定这个事情
阅读全文
摘要: 前几次的编码最佳实践系列，我们都着眼于Java代码，今天我们换个话题，看看另外一个领域，和Java代码大相径庭的SQL。
阅读全文
摘要: 本期的案例依然是来自实际项目，很寻常的代码，却意外遭遇传说中的Java"内存溢出"。
阅读全文
摘要: 昨晚继续折腾俺的小站http://www.javauniversity.net，准备给它加上SEO支持，安装了SEO tools模块和相应的依赖模块。
结果安装完成之后就陷入重定向循环了，每个页面都被重定向到新地址，然后新地址再次被重定向。chrome浏览器会稍后报错说太多重定向，而ie则傻傻的一直在死循环。
阅读全文
摘要: 折腾了两天，终于将Java University这个站点开通，过程真不容易的，决定写下来吐吐 糟，以纪念TIANCHAO和谐之光普照下P民的美好生活
阅读全文
摘要: 这是一个来自实际项目的例子，在这个案例中，有同事基于jdk中的LinkedHashMap设计了一个LRUCache，为了提高性能，使用了 ReentrantReadWriteLock 读写锁：写锁对应put()方法，而读锁对应get()方法，期望通过读写锁来实现并发get()。
阅读全文
摘要: 这里将要讲述的是一系列的类似案例，都是在各个产品进行performance tuning时被发现的，非常具有普适性。可以说在日常开发中，有非常大的概率遇到相同或者类似的情形，因此需要对其保持警惕以便避免陷入类似的性能问题。 我们从JAXBContext这个对象开始...
阅读全文
摘要: 这是一个真实案例，曾经惹出硕大风波，故事的起因却很简单，就是需要实现一个简单的计数器，每次取值然后加1......
阅读全文
摘要: 最近在公司内部做了一些收集和整理的工作，关于trouble shooting和performace tuning 中遇到并解决的典型问题，做了一些内部分享。我整理了一下，准备陆续放上来分享给大家。
这些问题，单个看每个问题都不算复杂或高深，但是都是在实际项目开发中出现并一度造成困扰的，而且带有一定的普适性，具体表现为不知道这些问题的同学很容易在日常开发中中招。因此我们开了一个专题，叫做编码最佳实践，似乎名字起的有点大......
先来看看第一个，如何做compare。
阅读全文
摘要: 今天用jetty做嵌入式web container，来做web项目的integration test，结果发现出现在渲染使用EL表达式的jsp页面时出现异常：
javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory;
检查了一下，发现javax.el.ExpressionFactory.newInstance()这个方法是EL2.2版本之后才有的方法，而在EL2.1之中是没有这个方法的，问题很明显：org.apache.jasper中试图调用2.2版本的EL，当时提供的EL的版本是2.1版本，所以解决的方式无非就是两个，要不降低org.apache.jasper的版本，要不提升el的版本。考虑到现在使用的jetty已经是最新的版本8.1.2.v20120308，因此提升EL的版本为2.2更为合适。
阅读全文
摘要: 在jenkins上建立了一个job，通过标准的maven命令来执行打包测试和上传artifact到nexus仓库。随后发现有些性能问题：sonar的job执行时，需要重新update SCM，然后需要再次执行test，之后才能进行真正属于sonar的任务如代码检测等。明显update SCM 和执行test是重复了原有job，纯属浪费。这个重复执行问题随着测试案例和测试执行时间的增加，会越来越明显。因此需要考虑消除这里的重复问题，减少build的时间，并节约jenkins的资源。
阅读全文
使用maven填写依赖的时候，常会遇到需要查一下groupId/artifactId和version，有时候还要看看有没有新的版本更新。
原来一直用http://mvnrepository.com/ 这个网站来搜索，最近发现maven官网也提供了类似的功能，http://search.maven.org/。
简单试用了一下search.maven.org，功能基本和mvnrepository.com相同，而且界面更简洁友好。推荐使用。
摘要: cloudfoundry是vmvare新推出来的开源PaaS平台，我试用了一下，发现还是很不错的，申请过程很简单。发出来分享给大家，有需要的可以去申请，毕竟可以支持java的免费的空间实在太难得了。
阅读全文
摘要: 初学gradle，一切都还在摸索的过程中。今天刚刚试图将之前基于ant + ivy的一个小项目转移到gradle下，结果在和sonar集成时出现问题.
阅读全文
摘要: 虽然easymock中提供了大量的方法来进行参数匹配，但是对于一些特殊场合比如参数是复杂对象而又不能简单的通过equals()方法来比较，这些现有的参数匹配器就无能为力了。easymock为此提供了IArgumentMatcher 接口来让我们实现自定义的参数匹配器。
阅读全文
摘要: 在easymock中，对于mock对象的同一个方法，可以为每一次的调用定制不同的行为。在record阶段easymock会精确的记录我们录入的行为，基于每一次的方法调用。
阅读全文
摘要: 前面的教程中，我们看到easymock可以通过expect方法来设定mock方法的返回值或者异常，但是注意这些案例中设置的返回值都是在调用被测试的类的方法前就已经确定下来的，即我们其实在测试类的代码运行前(实际是在EasyMock.replay()方法调用前)就已经"预知"了返回结果。
但是在某些情况下，我们可能无法预知返回值，比如我们需要根据输入的参数值来决定返回什么，而这个参数可能无法在record阶段获得。因此在mock方法中我们无法在record阶段就决定应该返回什么。
对于这种场景，easymock提供了IAnswer接口和andAnswer()方法来提供运行时决定返回值或者异常的机制。
阅读全文
摘要: easymock中提供对于类的mock功能，我们可以方便的mock这个类的某些方法，指定预期的行为以便测试这个类的调用者。这种场景下被mock的类在测试案例中扮演的是次要测试对象或者说依赖的角色，主要测试对象是这个mock类的调用者。但是有时候我们需要将这个测试类作为主要测试对象，我们希望这个类中的部分(通常是大部分)方法保持原有的正常行为，只有个别方法被我们mock掉以便测试。
阅读全文
摘要: easymock中提供了非常多的方法来实现参数匹配，基本能满足一般参数匹配的要求。
阅读全文
摘要: 在创建mock对象的时候，我们可以命名mock对象。
命名mock对象有什么好处呢？其实就是一点，即在当测试案例因为某个mock对象的状态或行为不符合要求而失败的时候，在异常信息里面可以输出这个mock对象的名称。
阅读全文
摘要: 对于mock对象上的mock方法的调用,easymock支持指定次数，默认为1.同时easymock提供了其他的方法，用于指定具体调用次数或者放宽调用次数检验。
阅读全文
摘要: easymock并不是万能的，在使用easymock时有一些限制需要注意。
阅读全文
摘要:
前面教程中有个章节讨论到mock和stub的概念差别，一般来说easymock如其名所示，主要是用来做mock用的，但是easymock中也提供有对stub的支持, 主要体现在andStubAnswer(),andStubDelegateTo(),andStubReturn(),andStubThrow()和asStub()等方法的使用上。
阅读全文
大家都知道sonar是个好东东，在有CI支持的情况下，使用好了可以非常好的控制代码的质量，诸如代码覆盖率，代码规则检查等。
而解决violation的办法，除了正统的修改代码来满足规则外，还有一个变通的方法， NOSONAR。这个标记本意是在一些特殊情况，有不得已的理由不得不违反规则，为了避免sonar继续报错而不得已做了一个"变通"。
NOSONAR本意虽好，但要是有人滥用，变通就会变成取巧，因为解决sonar violation的最简单的方法，就是直接NOSONAR！
当问题很简单时，一般人都会选择正常的方式修改代码，如果只是举手之劳基本上还是能遵守规则的。但是当问题复杂时，或者说当解决问题不再是举手之劳时，每个人都要受到NOSONAR的诱惑。而NOSONAR的底线在哪里？没有人定义，没有人检测，自然不会每个人都坚守，NOSONAR的底线随着一个一个的NOSONAR慢慢的在降低。退五十步的人，是没有资格笑百步的。
返回到现实代码中，不知道是大家都没有顶住诱惑，还是说我们开启的规则不大合理，总之越来越频繁的在代码中看到NOSONAR了，虽然还没有到泛滥的地步，但是已经让我有些不安了。简单搜索了一下刚才让我感觉到很多NOSONAR的project，结果是58个。
更糟糕的是，每个NOSONAR后面都不会带有注释说明为什么要NOSONAR，因此一个个飞舞的NOSONAR就变成了一个个谜团。想知道为什么要NOSONAR吗？恩，你猜......
我没有办法去检查这个58个NOSONAR是不是都合理的，都站得住脚的。出于程序员的习惯，对于一切不可确认性都报以怀疑的眼光和质疑的姿态，我总觉得这58个NOSONAR让我总是没有底，每次我看到sonar上100%的规则检测通过率时，我总是禁不住在心里浮现NOSONAR的字样。
好吧，我承认，我是个心里有些阴暗的家伙......
摘要: 在easymock的使用过程中，当创建mock对象时，我们会遇到 strict mock和nice mock的概念。上述的测试案例验证了strict mock和nice mock的基本使用，对于同一个mock对象，strict模式下多个方法之间的调用顺序在record阶段和replay阶段下是需要保持一致的。但是故事并不是到此结束，更有意思的内容在后面：如果出现多个mock对象，那么这些不同mock对象的方法之间，他们的调用顺序是否检测？普通mock和nice mock模式下自然是不会检测顺序，但是strict模式下呢？
阅读全文
摘要: IMocksControl接口容许创建多个mock对象，这些创建的对象自动关联到这个mocksControl实例上，以后再调用replay()/verify()/reset()时就不需要逐个列举出每个mock对象。当mock对象比较多，尤其是原有代码上新增mock 对象时非常方便。
阅读全文
摘要: 前面的例子中，mock的对象都是基于interface，虽然说我们总是强调要面对接口编程，而不要面对实现，但是实际开发中不提取interface而直接使用class的场景非常之多。尤其是一些当前只有一个明确实现而看不到未来扩展的类，是否应该提取interface或者说是否应该现在就提取interface，总是存在争论。
这种情况下，我们就会面临主要测试对象依赖到一个具体类而不是interface的情况，easymock中通过class extension 来提供对class mocking的支持。
阅读全文
摘要: 关于easymock的典型使用方式，在easymock的官网文档中，有非常详尽的讲解，文档地址为 http://easymock.org/EasyMock3_0_Documentation.html，文档的开头一部分内容都是easymock中最基本的使用介绍，虽然是英文，但是非常容易看懂，适用新学者入门。
这里只罗列一些简单的常用功能。
阅读全文
摘要: record-replay-verify 模型容许记录mock对象上的操作然后重演并验证这些操作。这是目前mock框架领域最常见的模型，几乎所有的mock框架都是用这个模型，有些是现实使用如easymock，有些是隐式使用如jmockit。
record-replay-verify 模型非常好的满足了大多数测试场景的需要：先指定测试的期望，然后执行测试，再验证期望是否被满足。这个模型简单直接，易于实现，也容易被开发人员理解和接受，因此被各个mock框架广泛使用。
阅读全文