关于JUnit使用的一点心得

[wargrey]

最近在用Junit做单元测试，但是发现一个很奇怪的问题，为什么大部分的教程，包括Junit的官方教程都是针对方法来测试（testXXX中XXX总是待测类中的方法名）？
这里就test方法应该怎么写说说我的看法。

在单元测试中，单元是指能独立完成某一任务的最小单位。很显然，在面向对象的世界里，这个单元就是类，而类的方法，即便是public方法，也不可能总是独立存在，这个跟类也需要和其他类交互是不同的，低偶合高内聚的原则正好说明了这点。

因此JUnit的每个test方法表示一套测试用例，不考虑setUp和tearDown的话，跟每个类单独的main方法的实质是一样的。


不知道我理解的对不对，各位达人指导一下。
谢谢

[淡泊明志-宁静致远]

用过一点点，但没有深入研究

[wargrey]

谢谢各位

[魔鬼代言人5800]

没用过，听起来有点道理

也有可能是你没有完全理解它的功能

[wargrey]

勘误：上面“因此JUnit的每个test方法表示一套测试用例”改为“因此JUnit的每个test方法表示一套测试方案”


为何自己不能修改自己的帖子

[wangydong]

高深，高手啊。

[wargrey]

[Quote=引用 13 楼 panhf2003 的回复:]
junit的测试对象是方法，因为junit是做的单元测试，而单元测试所做的事情是对一个模块的测试，而方法就是一个模块，一个入口，一个出口，实现一个最简单的功能。因此，我认为独立完成某一任务的最小单元不是类，而是类里面的方法。
junit单元测试所做的事情就是对每个类里面的每个public方法的测试。所以junit测试代码里面的每个方法都是testXXX的形式出现的。
[/Quote]
谢谢你的回复


一个入口，一个出口，只能说它是结构化的，不能说明他就是一个模块。

模块通常会提供与其他模块交互的接口，这点类比方法更能表达。甚至方法更本就不能表达，它只是一个消息而已，表明我做了这件事。

既然方法能够完成独立的任务，那在面向对象的语言里，为何做要把方法封装在类里面。而且高内聚的一个表现形式就是，方法的参数如果可以作为类成员就尽量这么做，但是一旦这么做，那这个成员就可能被其他方法接收。从而使得某个方法体的执行会改变其他方法的行为。所以方法不是独立存在的。就算是在非面向对象的编程语言中，比如C，模块的单位是文件（方法可以是static的表名作用域是当前文件），而不是方法。当然无论是类还是文件，它里面都可以只有一个方法，但是人们在使用“消息”时，还是会现考虑它隶属于谁。我们在查api时如何定位一个方法恰好说明了这一点。


另外补充说一下，我并不是说“test方法名”的方式不正确，而是这样容易让人误倒，从而局限了写test方法的思路。

[bianmazi]

说的有道理...

[panhf2003]

junit的测试对象是方法，因为junit是做的单元测试，而单元测试所做的事情是对一个模块的测试，而方法就是一个模块，一个入口，一个出口，实现一个最简单的功能。因此，我认为独立完成某一任务的最小单元不是类，而是类里面的方法。
junit单元测试所做的事情就是对每个类里面的每个public方法的测试。所以junit测试代码里面的每个方法都是testXXX的形式出现的。

[shengli_liao]

研究...

[zidasine]

很好 很深

[小雨转晴]

友情帮顶

[wargrey]

谢谢合作

[sun_cat]

juit是做最基本的测试的，最好涉及到的业务罗技越少越好，只有从最根本的地方保证正确性，才有可能保证最终的正确性

如果相对类来做测试，那类的输入就很多很多了，并且也不能找到作为代表性的东西

希望楼主能好好理解单元测试和集成测试的区别

[wargrey]

[Quote=引用 20 楼 sun_cat 的回复:]
juit是做最基本的测试的，最好涉及到的业务罗技越少越好，只有从最根本的地方保证正确性，才有可能保证最终的正确性

如果相对类来做测试，那类的输入就很多很多了，并且也不能找到作为代表性的东西

希望楼主能好好理解单元测试和集成测试的区别
[/Quote]

谢谢你。我也发现，似乎从类的角度出发，test会很难写，甚至比写正常的代码还麻烦。

[wargrey]

我发此贴的目的是想和大家一起讨论的

其实不管各位在平时的应用中有没有考虑这么多，我想或多或少都能给别人一起启发。

三人行嘛





希望参与讨论的人越多越好。

谢谢

[wargrey]

[Quote=引用 23 楼 panhf2003 的回复:]
你说得对，不过可能是我表述的不太对。一个方法不是说完成一个任务吧，而是一个动作，比如一辆车是一个类，倒车是一个动作，前进是另一个动作，它们各自对应一个方法，所以说把这些方法封装在车这个类里面是很有意义的，它们都是类的动作。而junit所做的事情就是测试类里面的每个方法是否正确的，测试这辆车前进有没有问题，倒车有没有问题。我想这就是junit单体测试的工作。（这个工作可能是业务逻辑层所做的，可能在控制层让这…
[/Quote]

恩。谢谢你的回复。


有关我说的“方法的参数如果可以作为类成员就尽量这么做”有两个原因（首先这句话本身，就是不成熟的总结，也需没有包含我想表达的意思）。
1.虽说面向对象的语言要用面向对象的思维，但是对于像我这样涉世不深的人来说，很多问题在考虑时其实还是觉得先有方法再有类，这样导致的一个问题就是单一的函数(对不起，在java里觉得将此类static方法成为函数可以使语言简洁的多，虽然这个不是java的术语)太多，放在一个全静态方法的类里面也显得不合适。所以我会尽量将方法包装在类了，这样一来，部分参数的个数介绍了，使得此方法也获得了类复用的优点。当然使用它可能会更麻烦一点。
2.我参加的SCJP，似乎sun也倾向于上述作法，并把此归于“高内聚”。

实际上我倒是觉得，如果合理的使用好setUp和tearDown方法，这样的作法并非不利于junit的测试。但是junit无法预测所有的系统类型、规模和输入。它本身的执行可能会耗调相当一部分资源，有点得不偿失。

也许对于我这样的初学者，针对方法的test写起来更容易下手。但是作为写单元测试的人，不应该将思维局限与此。

[panhf2003]

你说得对，不过可能是我表述的不太对。一个方法不是说完成一个任务吧，而是一个动作，比如一辆车是一个类，倒车是一个动作，前进是另一个动作，它们各自对应一个方法，所以说把这些方法封装在车这个类里面是很有意义的，它们都是类的动作。而junit所做的事情就是测试类里面的每个方法是否正确的，测试这辆车前进有没有问题，倒车有没有问题。我想这就是junit单体测试的工作。（这个工作可能是业务逻辑层所做的，可能在控制层让这辆车先前进后倒车，我们也会通过junit测试他有没有问题，总之，我觉得junit就是对方法的测试。）
另外，我觉得“方法的参数如果可以作为类成员就尽量这么做”的说法是不是也不太对，因为这样不利于测试和维护。以我的经验，在很多情况下，方法的参数是不作为类成员的，而是专门做一个objectclass来存放这些本来可以作为类成员的变量，这样就可以避免各个方法对同一个变量的操作，大大方便了junit测试（对方法的测试）。
不知道我有没有说清楚，请楼主指教。
[Quote=引用 16 楼 wargrey 的回复:]
引用 13 楼 panhf2003 的回复:
junit的测试对象是方法，因为junit是做的单元测试，而单元测试所做的事情是对一个模块的测试，而方法就是一个模块，一个入口，一个出口，实现一个最简单的功能。因此，我认为独立完成某一任务的最小单元不是类，而是类里面的方法。
junit单元测试所做的事情就是对每个类里面的每个public方法的测试。所以junit测试代码里面的每个方法都是testXXX的形式出现的。

谢谢你的回复


一个入口…
[/Quote]

[panhf2003]

引用格式没弄好，呵呵，不好意思。

[shlgsty]

[Quote=引用 23 楼 panhf2003 的回复:]
你说得对，不过可能是我表述的不太对。一个方法不是说完成一个任务吧，而是一个动作，比如一辆车是一个类，倒车是一个动作，前进是另一个动作，它们各自对应一个方法，所以说把这些方法封装在车这个类里面是很有意义的，它们都是类的动作。而junit所做的事情就是测试类里面的每个方法是否正确的，测试这辆车前进有没有问题，倒车有没有问题。我想这就是junit单体测试的工作。（这个工作可能是业务逻辑层所做的，可能在控制层让这…
[/Quote]
谢谢学习了

[g376983529]

谢谢