一般地說，你的類應具有開放的單元測試方式。然而，帶有直截了當的功能性的方法比如說，Java 語言里的Getting 和Setting 讀寫方法，就不需要單元測試，除非它們是以“特殊”的方式進行的。接下來的指導就是，當你感到需要對代碼中的某些特性添加注釋時，同時要編寫出單元測試。如果你同很多的程序員一樣，厭惡為代碼寫注釋，單元測試就是將你的代碼的特性文檔化的一種好方法。
將單元測試同被測試的相關的類打包在一起。(這種組織的方式允許每一個單元測試都能夠直接訪問類中被打包和保護的方法和參數)。要避免在單元測試中用到域對象(domain object)。域對象就是對于一個應用程序特定的對象。
例如，電子表格應用程序有個工作簿對象，它就是一個域對象。如果你的一個類已經知道了域對象，在你的測試中用到這些對象是很好的。但是如果你的類沒有涉及到這些對象，就不要在測試里讓它們同類糾纏不清了。不這樣做的話，就會產生打包的代碼被重用。經常是為一個項目創建的類也可以應用于其他的項目，這樣可能會出現直接重用這些類的情況。但是如果針對這些類的測試也用于另外的項目對象，讓測試生效會很費時，通常測試不是被拋棄掉就是被重新編寫。
以上的一些技巧會讓你從中受益，但最重要的是如果你不實際地去做，就永遠不會對單元測試有全面、深入的理解。更早地運行測試，并且在整個過程中都在代碼中給出全面的依據。當項目進展時，你會隨時添加更多的特性。運行測試就會提醒你，實現剛添加的特性會不會破壞已有的東西。
在你已經掌握編寫單元測試的技巧之后，你需要重新閱讀已存在的代碼。的確，為它們編寫代碼可能會是一場挑戰。但是千萬不要為了測試的目的而測試�？梢哉f，編寫測試是一件緊跟時效的事情，尤其是當你發現要修改一個沒有好的測試程序的類時，那就是添加測試的恰當時機。和平常一樣，單元測試應該具備類每個方法的特性。實現測試的一個最簡單的方法就是，測試的同時一定要注意代碼的注釋。在單元測試中，不能放過任何一個注釋，在描述測試方法的開始就要為單元測試添加大量的注釋中。
如何編寫功能測試
盡管功能測試是如此重要，它也有個開發過程里丑陋的繼生子的壞名聲。在大多數的項目里，是由一個獨立的工作組來完成功能測試的工作。通常需要一群人在系統中的相互協助才能保證工序的正確運行。這種通常的看法和隊伍的組建的做法，都是非常愚蠢的。
功能測試同單元測試相類似。一旦要編寫有用戶涉入的產品的代碼(例如，對話框)時，就要編寫測試，但是一定要在實際編寫代碼之前做。一旦你開始了一項新任務，就要在功能測試的框架里清楚地描述這個任務的內容。你加入的新代碼的同時進行單元測試，開發工作就向前持續進行。
當所有的單元測試都進行通過后，再進行最初的功能測試來判斷項目是否可以通過，或是需要修改。理想的狀況下，功能測試小組的概念應該不存在的。開發者應該同用戶一同編寫功能測試。系統通過了一系列的單元測試后，負責進行功能測試的小組成員就要改變初試測試的參數，再進行系統的功能測試。
單元測試和功能測試之間的界線
一般情況下，很難劃清在單元測試和功能測試之間的界限。說實話，一直以來，我就不知道這個界線應該定在哪里。當編寫單元測試時，我用以下幾個方法來判定單元測試是不是已經變成了功能測試：
如果單元測試超越了類之間的界限，它可能變成了功能測試
如果單元測試變得非常的復雜，它可能變成了功能測試
如果單元測試變得很脆弱(即是說，它已經成為一個測試，但是卻因為要迎合不同用戶需求的改變而被動地變化)，它可能變成了功能測試
如果單元測試比需要測試的代碼還要難于編寫，它可能變成了功能測試
文章來源于領測軟件測試網 http://www.kjueaiud.com/
