2 回答

TA貢獻(xiàn)1790條經(jīng)驗(yàn) 獲得超9個(gè)贊
TDD 中通常的答案是您將函數(shù)分為兩部分;一個(gè)易于測(cè)試的部分,但與特定文件句柄或 os::Exit 的特定實(shí)現(xiàn)不緊密耦合;另一部分與這些東西是緊密耦合的,但是如此簡(jiǎn)單,顯然沒(méi)有任何不足之處。
您的“單元測(cè)試”是測(cè)量第一部分的錯(cuò)誤檢測(cè)器。
第二部分你寫一次,“用手”檢查它,然后不管它。這里的想法是事情是如此簡(jiǎn)單,一旦正確實(shí)施,它們就不需要改變。
// Warning: untested code ahead
func Foo_is_very_stable() {
bar_is_easy_to_test(stdin, stdout, os.exit)
}
func bar_is_easy_to_test(in *File, out *File , exit func(int)) {
// Do complicated things here.
}
現(xiàn)在,我們有點(diǎn)作弊——os.exit這是一種永遠(yuǎn)不會(huì)回來(lái)的特殊魔法,但bar_is_easy_to_test并不真正知道這一點(diǎn)。
另一種更公平一點(diǎn)的設(shè)計(jì)是將復(fù)雜的代碼放入狀態(tài)機(jī)中。狀態(tài)機(jī)決定做什么,調(diào)用機(jī)器的主機(jī)決定如何做……
// More untested code
switch state_machine.next() {
case OUT:
println(state_machine.line())
state_machine.onOut()
case EXIT:
os.exit(state_machine.exitCode())
同樣,您會(huì)得到一個(gè)易于測(cè)試的復(fù)雜部分(狀態(tài)機(jī))和一個(gè)更簡(jiǎn)單的穩(wěn)定且易于通過(guò)檢查驗(yàn)證的部分。
這是 TDD 的核心思想之一——我們故意以“易于測(cè)試”的方式設(shè)計(jì)我們的代碼。這樣做的理由是聲稱易于測(cè)試的代碼也易于維護(hù)(因?yàn)楹苋菀讬z測(cè)到錯(cuò)誤并且因?yàn)樵O(shè)計(jì)本身“更干凈”)。

TA貢獻(xiàn)1786條經(jīng)驗(yàn) 獲得超11個(gè)贊
你所擁有的東西被稱為“副作用” - 當(dāng)你的應(yīng)用程序的執(zhí)行跨越它的環(huán)境時(shí),它是地址空間的情況。問(wèn)題是,你不測(cè)試副作用。這并不總是可能的,而且當(dāng)它是 - 它是不合理的復(fù)雜和丑陋的。
基本思想是讓你的副作用,如 CLI 輸出或os.Exit()
(或網(wǎng)絡(luò)連接,或訪問(wèn)文件),與你的邏輯主體分離。有很多方法可以做到這一點(diǎn),整個(gè)“軟件設(shè)計(jì)”學(xué)科都致力于此,@VoiceOfUnreason 給出了幾個(gè)可行的例子。
在您的示例中,我將在函數(shù)中包裝副作用并安排某種方式將依賴項(xiàng)注入Success()
& Error()
。如果您想保留這兩個(gè)簡(jiǎn)單的函數(shù),那么它要么是函數(shù)參數(shù),要么是持有退出函數(shù)的全局變量(根據(jù)@Peter 的評(píng)論),但我建議采用 OO 方式,采用一些 模式并實(shí)現(xiàn)更大為您提供靈活性。
- 2 回答
- 0 關(guān)注
- 181 瀏覽
添加回答
舉報(bào)