对junit的一点体会

Junit是自己写的，如果写得不过严格，或想得不够周到，不知有没有可能变成Pandora's box , 说到底还是得靠自己的Coding Ability，不知大家有何高见呢？

其实我觉得单元测试很难写的，特别是涉及到对数据库的操作，setup和teardown方法怎么写，是颇费脑筋的，有时候写unit test感觉到比写代码还要费事。

以前曾经干过这样的事：能加main的加main，不能的再写TestXXX，复写tostring也干过……
感觉很不规范……

各位能谈谈JUnit的实战体会吗？

我在做数据库应用开发的单元测试时，发现没有一个独立的数据库层是很难进行单元测试的。
如果有了数据库层，可以使用Mock Object技术来代替数据库层，从而可以对业务层进行单元测试。
但是数据库层的单元测试该怎么做，我也没有好办法，大拿们来讨论讨论。

涉及到数据库操作的单元测试，最好是编写一些辅助清除类。

为保证测试可回归，需要保证每个单元测试的结果不受其他测试的影响，不管其他测试是成功还是失败的。

可以有两种方式来保证，一种方法是每个单元测试完成时(tearDown)清除所有本单元测试产生的数据，还有一种方法是在Setup里面做。我偏向于后一种，这样比较清楚一点。虽然是单元测试，但由于数据库约束，可能需要涉及到非本单元测试重点关注的其它类的数据产生和清除。类似这些东西，我喜欢把他们集中到一个TestUtil类里面。

另外就是每个单元测试通用的代码，例如建立参考性数据（如国家、地区代码等等），应该在建立测试的过程中不断抽象，放到一个实用程序类里面。

调用TestUtil的方法清除其他TestCase的余留数据，数据库联接的建立，DAO的获取，Service对象创建，按照你的框架（例如用Ioc或者想我原先的Flex)，可以抽象到一个Test超类里面，其他的子类可以从这个超类继承，象事务的启动可以放在超类的Setup以及TearDown里面，为子类提供方便。

另外，不同层次的包(package)可能有不同的重点，例如实体层、DAO曾、服务层、展示层等等，这些类的代码可能还可以在抽象出中间的TestCase。

你不需要一开始就把所有的测试类层次都做好，主要是可回归原则和重用原则，注意TestCase的重构，慢慢就会形成类似我所讲得测试类结构的。

使用junit测试，代码量几乎增加一倍，而且感觉不是所有的地方都测试到了。可能是测试用力写的不好。

总之现在我又回到用main来测试了。

如果我没判断错误的话，你是先写好所有的代码逻辑再写测试的，这不但会重复你所有的调试过程，渐进设计过程，而且极易产生厌倦心理。
Main测试估计就是敷衍了事，开始可能认真一点，以后就会越来越少

如果你没办法一下子TDD，那么就做到写几句代码马上测试，拖的时间越长，厌倦心里就越强烈，测试的作用也越不明显，甚至基本上写不出多少有用的测试。

除了功能测试，我从来不为单元测试正式写测试用例,测试是在编码过程中逐渐完善起来的。

我的思路是另外一种。在本地使用一个轻量级的数据库，然后一些基本的测试数据放到xml文件中，每次跑test case的时候用dbunit导入，好处就是数据的清除，初始化比较简单，改xml就好了，不用写代码。坏处就是慢一点。
对于测试代码，现在还有一种思路，就是用groovy这样的脚本语言来写，减少代码量，不过我感觉没有好的ide支持，效率提高很少。不知道这位大虾有什么
想法？

这句话怎么解释？
java的另外一个问题就是框架应用太多了，如果写ut，有时候就不不自己先写
一个比较复杂的测试框架，很痛苦，分层是一个办法，可是有些问题，分层没有意义。头大呀。我发现自己从写一点ut，写一点code,逐渐演变到写一点，补一点ut了。

单元测试是在编写代码前（最多是每编写几行代码后）就应该加入的，单元测试的发展过程就是详细设计的过程。
单元测试主要目的是测试单元，具体的来讲是测试一个类，必须保持这个类的单元测试和其他的单元测试完全独立。进一步，一个TestCase里面的所有testXXX都应该相互独立，这是我前面需要在Setup里面清除数据的原因.

输入的数据不是由客户的某一个测试用例预定的，而是针对开发过程中不断出现的设计和问题。单元测试的输入数据、执行单元的功能，检查执行结果是一个不断出现的交叉过程，最好显式用代码表达出来。这也是一份详细设计书，同时也是后来者学习如何使用该单元的说明书。
XML没有代码的这个优点，它可以用于功能测试（接受测试），用户的测试可以清楚地用输入数据(XML)表达出来。