2015-04-12 98 views
0

我有一個方法,我想單元測試,一個檢查三張卡之間的匹配。由於卡片是隨機生成的,因此無法設置我知道會匹配或不匹配的三張卡片。我需要這樣做來單元測試我的isMatch()方法。修改源代碼以使單元測試有效嗎?

是否可以改變我的卡類添加一個方法來顯式設置它的值,所以我可以單元測試它?一般情況下,對源代碼進行小的添加以使單元測試成爲可能或者是否有更好的或正確的方法可以接受?

+1

你應該將隨機性的來源「隨機」實例注入你的類中。在你的測試中,你可以創建一個已知的隨機序列並測試邏輯。代碼應該寫成可測試的。如果它不是可測試的,那麼應該改變它。 –

+0

你是不是在爲你的隨機性使用種子?沒有小寫日誌文件,所以你可以重新創建? –

+0

@BoristheSpider,你可以詳細說明注入'Random'實例嗎?我不清楚你的意思。 – Hal50000

回答

1

不知道你的設置是什麼,但爲什麼不讓卡片發生器成爲你班級的可插拔組件,並且fake保證返回三張匹配的卡片?

然後,你可以fake一個類,保證返回三張不匹配的卡。

+0

我考慮過使用卡片發生器,或者更具體地說使用CardFactory或CardBuilder。問題是Card類不需要大量的自上而下創建。所以我寫了卡片類來管理自己的隨機化。當其他類需要一張卡片時,他們只需要調用默認的構造函數,他們可以期待隨機卡片。我相信自下而上的設計會更好,但它確實需要添加更多的代碼才能明確地創建卡片,因此可以測試「isMatch」方法。 – Hal50000

+0

做你正在做的事情當然很好,但是現在向卡類添加隨機化,你永遠不會有用於生成卡片的不同策略。這是一個很好的決定,但它確實會帶來一些後果,因爲你很可能已經注意到了。就像無法寫出清晰簡潔的單元測試一樣。 [Bob叔叔](https://sites.google.com/site/unclebobconsultingllc/)會說你的卡片類有兩件事,一般來說一個班只能做一件事。 – hooknc

+1

將卡接口改爲接受配置對象將是微不足道的。畢竟,我並沒有寫一個API,所以「從來沒有一個不同的策略來生成卡」並不完全是一成不變的。你的建議是一個很好的建議,我最初寫它時確實考慮過。問題是沒有自我配置,Card類只是一個數據結構,持有卡的屬性;那也不是很好的設計。正如你所提到的那樣,整個設置並不爲你所知,但我認爲你的答案是最有用的。 – Hal50000

-3

不可以。你不應該爲你的單元測試修改你的代碼並修改它,所以「代碼運行」。對於所描述的問題,您有@Before。圍繞此設計你的課程。構建三張確定性卡並進行比較。通過這個註釋,您可以測試代碼的功能,而無需「修改代碼進行單元測試」。

+0

我正在使用@before。這不是問題,問題是當前的界面沒有創建卡片的確定性方法。這不是代碼運行的問題。它運行在兩種情況下,在原來的,如果我添加一個方法,使卡確定性。我只是問是否向源添加方法是「正確的」,以便測試可以完成。 – Hal50000

+2

@ Hal50000這絕對沒錯。 – Turing85