前一陣子在看關(guān)于TestNG的東西，不小心看到Cedric的一篇blog（http://beust.com/weblog/archives/000171.html），突然得到很多啟發(fā)。
這篇blog講的是方法的依賴，然而最讓我感興趣的是下面的回復(fù)。

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).

看到這，我突然想到有本單元測試的書，一開始就告訴我們，單元測試是獨(dú)立的，沒有順序，不互相依賴，從這個理論看，Junit的做法是絕對正確的，而TestNG的dependent完全是沒有必要的。

然而我懷疑的是，我們是否能夠做到真的獨(dú)立的測試每個方法？
最簡單的例子
方法A調(diào)用了方法B，為了讓方法A不依賴于B的正確性，我們通常的做法是什么，Mock。沒錯，我們會做一個Mock B，然后可以告訴自己，我們可以獨(dú)立的測試A，因?yàn)槲覀冏隽藗€假的Mock B，而Mock  B是絕對正確的，所以在測試A的時候我們不用考慮B了。
然而考慮一下如果B做了下面的事
1。往數(shù)據(jù)庫做了操作（增刪查改）
2。修改了某配置文件
3。往Jms發(fā)送了某消息
當(dāng)然還有很多，這些事你能Mock的了嗎？ok，總會有牛人把這些都能Mock了，實(shí)現(xiàn)了，然而你要回答我一個問題，如果你的Mock把這些事都做了，那他和真實(shí)的方法B又有什么區(qū)別？（補(bǔ)充一下，并不是否定Mock的作用，我認(rèn)為Mock最大的作用在于模擬正常情況下無法或者很難出現(xiàn)的情況，特別是拋出某個異常）

個人認(rèn)為，在現(xiàn)在的配置環(huán)境越來越復(fù)雜的情況下，方法正在喪失他的獨(dú)立性，要想獨(dú)立的測試A或者B已經(jīng)是越來越難的一件事了，真正對立的方法只有在Sun的API那里才有（沒有貶低的意思），只有輸入和輸出。

在傳統(tǒng)的單元測試?yán)碚撓旅妫覀冇刑嗟碾y題，數(shù)據(jù)庫（現(xiàn)在有些工具，例如DBunit，但我看解決不了所有的問題），MVC中的Action，顯示層，我們突然發(fā)現(xiàn)對每一個類型的方法，我們都要使用特定的工具去解決他們的測試的問題。

TestNG并不能解決所有的問題，但我想是一個正確的方向，這絕不僅僅是框架之爭，而是我們到底該如何進(jìn)行我們的單元測試。我極贊同下面的話：
The problem is that the core of JUnit has not changed with the changes in it the way that developers use it.

下面基本屬于本人的胡思亂想：
我們開始造馬車，發(fā)現(xiàn)每個最小的單位都是有功能的，比如輪子，馬。然后我們造汽車，我們的最小的單位變成了某個螺絲釘，或者是一個齒輪，我想說的是一個螺絲釘離開了發(fā)動機(jī)，它什么都做不了。