看看测试多重要

前些天测试中发现，缓存好像不能处理数据变更的情况。原来还是好好的阿。
经过跟踪，发现问题出在UpdateTimestampsCache，不知哪位仁兄手快，改了一行if语句，把原来正确的逻辑改错了。在7月13号到11月15号之间，下载的hibernate都有这个BUG。

				return lastUpdate.longValue() < timestamp.longValue();
//				if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;

从这件事情，引申出另外一个问题，测试是如何的重要。
如此重要的特性在四个月后才得以修复，应该说hibernate的测试工作是有问题的。至少，在多对象连接的情况下，缓存没有测试。

没有测试的代码就是这样可怕，浪费时间和精力不说，还打击了信心。
所以说，测试工作怎么强调都不过分阿。

是啊，测试工作都交给用户去做了。
除了俺们自己写的程序，还得去替使用的这些框架和JAR包做测试。
所以我觉得除非有必要，不用经常更新所有的jar到最新版本，稳定第一。要是系统中换了某一个jar包，就得把所有的测试流程再重走一遍才行，谁也保不准哪个地方会出错的。

这个错误简直是不可原谅的。

不过就此也引出一个问题，在循环里直接return返回值，虽然语法上没问题，但是就逻辑而言，很容易出错。像这个错误的产生，就是由于修改代码的人，简单的认为

if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;

等价于

return lastUpdate.longValue() < timestamp.longValue();

，而没有看清楚原代码中当lastUpdate>=timestamp时，是不会跳出循环去return的。

严格一点来说，方法的返回值，是否应该在方法体的最后统一提交更好一些呢？而不要在方法中出现很多的return。

另外采用缓存策略还有一点不知如何处理为好，就是当缓存已经存在的时候，服务器的系统时间被回退，这样lastUpdate时间就可能小于timestamp，但实际上缓存应该是被更新的。这种可能性不是没有的。
是否可以这样来处理，每次的操作均在系统中记录最后一次的操作时间，一旦新的系统时间小于上次操作时间，则系统终止运行，并报错。类似某些有试用时间限制的软件防破解一样，即使把系统时间改回，也一样无法继续试用。

比如循环就会变成while(iter.hasNext() && returnValue)。
这会导致相关的执行路径要关心这个返回值，增加复杂性。

所以感觉java语法相比过于严谨的pascal，还是太灵活了。
像下面的写法，确实增加了关注点。比如while(iter.hasNext() && notFindCacheToUpate)
但如果直接return的语句多了，是比较容易出错

还是回归到测试的覆盖度上。有一套全面的测试手段，就能从一定程度上避免问题。

是啊，有一套效验程序是否正确的保护网，确实很重要。