测试文件应该放哪里?

最近在读Kent Beck的《测试驱动开发》,这也是Michael Feathers在《修改代码的艺术》一书中推荐的重构方式。初时觉得文中的Test Driven Developing (TDD)的方式显得十分繁琐,每次新建测试然后再编写类的实现也让人觉得本末倒置,颇有“代码未动,测试先行”的味道。但重新再读一次时感觉思路清晰了不少,也理解先写测试更多的是从应用的角度来设计。其实编写代码和测试的习惯可以因人而异,先写代码还是先写测试或许应该可以根据个人喜爱而安,毕竟无论是代码还是测试都会随着开发的进展而不断迭代的。

关于TDD的好处就不在此重复了,不过之前我写单元测试时都是直接把测试的代码和待测试类放置在同一个包内,毕竟这是Eclipse的默认方式,使用起来最方便。结果在新Mentor李总代码检查时就指出我需要将mock和test文件与程序源代码分离。所以这篇日志只是想探讨一个问题:自己编写的单元测试文件应该如何放置。

在JUnit的官方网站FAQ中,可以看到主要有放置在相同包内、建立包下的test包以及建立test并行目录方式三种方式。其分别的优缺点如下:

放置在相同包内:
优点

  • 方便。毕竟Eclipse默认方式便是如此,直接新建一个测试类后回车即可。
  • 直观。能很方便看到哪些类写了测试而哪些没有写(前提是测试类名按通常标准定为SomeClassTest.java)。
  • 灵活。某些方法定义为包内可见,以方便测试而又不必对外公开。此时测试类与待测类在同包内才能读取相关方法。

缺点

  • 混杂。功能代码与测试代码放在一起会造成发布代码时不便,虽然可以使用Ant工具将所有的Test文件exclude,但终究还需要进行额外的配置操作。
  • 干扰。虽然放一起能较方便了解哪些类经过了测试,但也会因为包内类的数量几乎翻了一倍而增加开发时寻找相应类的难度,增加开发负担。这种现象在类名有过修改而测试类名并没有对应更新时更加明显。

增加test包

增加测试目录有两种方式,一种是在相应的包内建立test包,如com.package.test。另一种则是建立test为根的包,如test.com.package。相比之下,后者会更加方便一些,因为在发布成品时直接将test下的文件全部剔除即可。不过由于此时的test包是作为代码的一个子包,与com.package并不属于相同的包,所以无法直接测试com.package包下的类的包可见方式,测试时略有不便。

建立test并行目录

粗看时似乎和上面的建立test为根的包一样,其实不然。这种方式是建立与src文件夹同级的test文件夹,然后保持test文件夹与src文件夹目录结构相同,从而实现测试代码与待测试类属于相同的包内。具体的做法是在项目上点右键,选择New->Source Code,然后输入test即可。自行实践一下便知道方法3与方法2的微妙差异,而正是这点小差异让方法3在保全方法1的全部优点时避免其大部分缺点,也是现在软件开发的推荐做法。只是这样在新建测试类时,需要将Source Folder从src更换到test。

至于重构类名后造成与测试类的类名与重命名后的类不一致的问题,其实也可以通过顺带更新一下测试类名来保持一致。个人觉得如果不是偏执狂的话,其实没必要时刻保持测试类名与待测试类类名完全一致。尤其是在将一些大类重构成若干小类时,分造成功能的分解,这时重新新建一个测试类来测试的工作量也不会太大。原先的测试继续保留,因为测试毕竟是愈充分愈好,配合着这个Ant脚本运行全部测试,便可很方便地了解先前所做的修改是否造成了不良的影响了。

 

Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: