前一阵子在看关于TestNG的东西，不小心看到Cedric的一篇blog（http://beust.com/weblog/archives/000171.html），突然得到很多启发。
这篇blog讲的是方法的依赖，然而最让我感兴趣的是下面的回复。

I don't buy your arguments. It just looks to me as though you're overlooking the "unit" aspect of JUnit.

The premise of JUnit is that a TestCase is a collection of independant tests. The setUp method MUST therefore be called before each test because that is how the tests are made independant : its responsibility is to setup up the environement.
That is also why you will get 20 failures : each test is independant, the only relationship between them is that they use the same setUp method (or, as almost everybody using JUnit does, they refer to the same Class to test).

看到这，我突然想到有本单元测试的书，一开始就告诉我们，单元测试是独立的，没有顺序，不互相依赖，从这个理论看，Junit的做法是绝对正确的，而TestNG的dependent完全是没有必要的。

然而我怀疑的是，我们是否能够做到真的独立的测试每个方法？
最简单的例子
方法A调用了方法B，为了让方法A不依赖于B的正确性，我们通常的做法是什么，Mock。没错，我们会做一个Mock B，然后可以告诉自己，我们可以独立的测试A，因为我们做了个假的Mock B，而Mock  B是绝对正确的，所以在测试A的时候我们不用考虑B了。
然而考虑一下如果B做了下面的事
1。往数据库做了操作（增删查改）
2。修改了某配置文件
3。往Jms发送了某消息
当然还有很多，这些事你能Mock的了吗？ok，总会有牛人把这些都能Mock了，实现了，然而你要回答我一个问题，如果你的Mock把这些事都做了，那他和真实的方法B又有什么区别？（补充一下，并不是否定Mock的作用，我认为Mock最大的作用在于模拟正常情况下无法或者很难出现的情况，特别是抛出某个异常）

个人认为，在现在的配置环境越来越复杂的情况下，方法正在丧失他的独立性，要想独立的测试A或者B已经是越来越难的一件事了，真正对立的方法只有在Sun的API那里才有（没有贬低的意思），只有输入和输出。

在传统的单元测试理论下面，我们有太多的难题，数据库（现在有些工具，例如DBunit，但我看解决不了所有的问题），MVC中的Action，显示层，我们突然发现对每一个类型的方法，我们都要使用特定的工具去解决他们的测试的问题。

TestNG并不能解决所有的问题，但我想是一个正确的方向，这绝不仅仅是框架之争，而是我们到底该如何进行我们的单元测试。我极赞同下面的话：
The problem is that the core of JUnit has not changed with the changes in it the way that developers use it.

下面基本属于本人的胡思乱想：
我们开始造马车，发现每个最小的单位都是有功能的，比如轮子，马。然后我们造汽车，我们的最小的单位变成了某个螺丝钉，或者是一个齿轮，我想说的是一个螺丝钉离开了发动机，它什么都做不了。