測試控制器

測試不應該是很教條的，相反的測試工作應該達到的狀態是能夠讓我們加快開發速度，並且讓我們的工作更加的有趣。

測試簡單的任務是簡單的，測試複雜的工程是複雜的，我們這裡想要討論的是如何讓事情保持簡單和盡可能小，這樣的話完全是有利於測試工作的進行的，是雙贏的工作。保持事情的簡單性其實就和tdd(test-driver development)相似的，有人喜歡它有人厭惡它，此文的目的並不在tdd上，所以我們僅僅是粗略的概述一下tdd的概念：在編寫**之前，測試人員首先會在對於系統新的改進和功能函式的需求的基礎上建立自動的測試用例，並在這個前提之下，盡量使用最少量的**來通過測試用例，最後修改**進行重構，並且確保重構之後的**遵守系統的**標準。

對ui元素進行測試往往都是很困難的，因為ui元素包含了太多的移動的內容。而控制器面對的情況其實更加的複雜，因為控制器和view層和model層的很多類都有著聯絡。為了能夠對控制器進行測試工作，我們需要讓不同層次之間的工作能夠分開進行。

我們期望的是這樣的：在更加乾淨的控制器那篇文章中讓控制器更加的乾淨的的那些方法一樣也能夠讓我們的測試工作更加的簡單。通常情況下，如果你發現測試工作讓你十分痛苦，那麼這其實就是暗示你的設計或許很糟糕，需要重新進行設計或者**的抽取才能讓測試工作變得簡單。我們總體的設計目標是讓不同層次之間層次分明，關係清晰。最佳的設計其實就是：我所創造的每乙個類只去做一件事情，並且它需要把自己分內的工作做的很好。這樣話對每乙個類進行的測試都是非常的簡單的。

mark：新增的測試越多，得到的返回結果越少！首先也是最終要的是要保持測試的簡單性！

當我們將複雜的事情分散到很多的類中分別進行的時候，我們測試的工作將會變得異常的簡單：只需要分別測試每乙個獨立的類就可以了。我們正在測試的這個類和其他的類之間有著聯絡，我們通過使用乙個**仿造品（mock

or stub

. ）來避免這種聯絡。其實可以把這乙個仿造**看做是佔位符，這樣的話我們測試的這個類就是和這些佔位物件進行聯絡了，而不是真正的物件。這樣的話我們就可以專心在這個類的測試上，而不用擔心其他的類對測試這個類的干擾。

oc中的模擬**的強大工具是

ocmock，這是乙個影響了objective-c的執行時(runtime)的作用和靈活性的非常成熟的工具。

另乙個我們需要用到的測試框架sentestingkit現在整合在了xcode中，它的作用是執行測試**，通過sentestingki你完全可以將測試**組織到乙個類中去。在這些測試類中的每乙個方法都需要有具體的測試功能(職責)而且方法名要以test開頭，test是在執行時將方法解讀為測試的標誌，可以重寫-setupand-teardown兩個特殊方法來初始化測試，需要記住的重要的一點是：測試類也只是乙個類，如果能夠幫助你進行測試工作那麼就不要猶豫直接向裡面加入需要的屬性和方法。

在測試的時候還有一點是，通常我們會先創造乙個測試的基類，並且在這個基類中存放一些通用的邏輯**以便幫助我們更加專注的進行測試工作。通常我們也不會使用xcode的模板進行測試工作，我們僅僅是新增乙個簡單的.m檔案，為了方便我們命名這個類的時候在用tests作為結尾，而且這個類的名字應該反映這個類的測試用途。

測試會內建到你選擇的靜態庫和資源包種去，如果你的測試需要特殊的資源檔案，直接加入到測試目標中去xcode會把它們放入到資源包中的。然後你可以使用nsbundle進行定位操作-urlforresource:withextension:

static bool isrunningtests(void) __attribute__((const));
didfinishlaunchingwithoptions:(nsdictionary *)launchoptions
//// normal logic goes here
//return yes;
}static bool isrunningtests(void)

可以在xcode中編輯scheme給了我們很大的靈活性，你可以在測試執行之前或者之後執行特定的指令碼，而且也可用使用很多的測試包，對於大型專案這些都是很重要的。更加重要的是我們可以開啟或者關閉特定的測試**，這在進行debug測試的時候異常重要，但是別忘了在結束之後都開啟。

測試控制器

通過Mock測試控制器

jmeter控制器交替控制器

NAND控制器驅動測試方法

測試控制器

通過Mock測試控制器

jmeter控制器 交替控制器

NAND控制器驅動測試方法

相關推薦

jmeter控制器交替控制器