测试的粘结度

最近一直在写操作符处理的单元测试。正如liangfei所说，想要更好的优化表达式，首先得十分了解操作符的功能，而写单元测试就是非常好的一个途径。十分赞同这个观点，所以我最近一直在写测试，也确确实实地了解了操作符的功能。

 

在测试类中如何获得操作符对象呢？我参考了一下写完的测试类，发现是 new 出来的。可是在程序中，操作符不是new出来的，而是通过一个IOC容器获得的，而且获得是某一种操作符的handler，例如下面这样：

 

Configuration config = PropertiesConfigurationLoader.loadStandardConfiguration();
// 默认会取得 StandardOperatorHandlerProvider
operatorHandlerProvider = config.getOperatorHandlerProvider();
handler = operatorHandlerProvider.getUnaryOperatorHandler(".");

 

这个handler就是处理"."符号的了，通过这个handler，再去调用"."号操作符。这么做的目的我想是为了实现操作符的重载。

 

所以，在CommonTemplate里，是不可能直接得到操作符对象的。因此，在测试类中，我也就使用了这种方式，来获得操作符进行测试。

 

不过liangfei并不同意这种方式。他认为测试操作符的时候，应该在测试类中 new 出操作符，然后对操作符进行测试。理由是这样可以把要测试的目标功能分隔开来。我的理解就是降低测试的粘结度。但是这样就产生另外一个问题，如何保证 OperatorHandler的正确性？

 

或许应该再编写测试类，从 OperatorHandler 开始，测试到每一个操作符。这样确实很麻烦。但是如果不做这种测试的话，又不能保证 OperatorHandler 的正确性。

 

那么测试的粘合度如何控制比较好？例如一个项目，有业务层，和持久层。那么当对这两个层写测试的时候，改如何进行？

 

按照所理解的TDD的方式，在实现持久层的时候，必然会写持久层的测试。在写业务层的时候，再去写业务层的测试，这时，业务层的测试也间接包含了持久层的内容。那我们是不是可以跳过持久层的测试？当然不可以。

 

所以问题又回来了，对于CommonTemplate来说，我们是不是可以跳过操作符的测试？当然不可以--事实上我们也确实没有跳过，现在写的就是操作符的测试。那么我们可以不可以跳过 OperatorHandler 的测试？也是不可以。不过，OperatorHandler 中逻辑很少，只是按照责任链的模式把变量分配到正确的操作符上。

 

因此，我们是不是可以把 OperatorHandler 的测试和操作符的测试一起做了？虽然这样做测试粘合度比较大，但是 OperatorHandler 的逻辑几乎没有，如果再单独对它进行测试，就和测试操作符完全重复了。

 

所以，是不是也可以这样考虑，两个类，虽然有关联，但是其中一个类没有逻辑，或者逻辑非常少，那么可以不考虑粘合度，而直接对这两个类一起进行测试？

 

这个问题我不知道答案。不过我还是遵从liangfei的意见，按照降低粘合度的方式修改了测试类。希望能在以后的积累中，得到一个满意的答案。