2016-04-28 42 views
1

我目前正在掌握Lucene索引,並且如果使用TDD,我會對「正確」方法感到頭疼。TDD - 這種依賴序列情況的方法是什麼?

要做到這一點,你有一個基於文本的簡單集合(絃樂),這是記號化創建的IndexWriter,生產指數,莖等

要查找查詢此索引你有創建一個DirectoryReader,進行查詢,獲取命中等。

因此,在製作我的第一個測試類(JUnit 4)的過程中,我逐一完成了這些步驟,爲如果一切順利的話,這個過程中的每一步最終都會產生非零的點擊次數。

我遇到的問題是,最後一個測試方法會執行所有這些步驟:清除索引目錄,創建IndexWriter,製作索引等等,最後統計命中次數。最後一種方法最終可能會被錯誤的方式絆倒。此外,以前的方法都顯得多餘......!似乎沒有「嘲弄」的機會......

這是「測試套件」的候選人嗎? TDD Pro如何爲這種情況開發「適當」的測試?

回答

1

這聽起來對你來說,你所指的最後一種測試方法更多的是集成測試而不是單元測試。單元測試應該只測試一個非常特定的代碼單元(通常是方法或方法的一部分),並且應該模擬與其他類的任何交互,不應觸及數據庫,文件系統或任何超出特定代碼單元的任何內容測試。這聽起來像你創建的第一個測試是單元測試,最後一個測試是集成測試。由於單元測試正在測試非常具體的邏輯塊並且集成測試測試了這些塊之間的交互,所以在這兩種類型的測試之間有一些重定位是可以的。

+0

謝謝...實際上,在這個最後一個測試之前還必須做很多事情:製作索引,並測試它是否可以打開查詢索引...換句話說,大約有4個步驟:第一個測試方法做1步,第二步做2步,第三步做3和第四步4.沒有辦法「嘲笑」這些測試的任何先決條件,因此需要進入相當尷尬的重複。此外,沒有辦法不碰觸文件系統......所以,這些似乎是集成測試......作爲一名新手,我只是想知道專業人員如何處理這種情況。 –

+0

如果沒有辦法模擬外部交互,我會感到驚訝。通常可能,只是不總是可行的。你總是要評估你所付出的努力的價值,所以在這種情況下,只需編寫集成測試就可以了。我從你的描述中想知道你的測試是否相互依賴。這通常是不好的做法,因爲它使得難以確定錯誤,雖然可能有些情況證明它是正確的。您還需要確保您的junit版本可以保證運行順序。 – TheEllis

+0

再次感謝...是的,我目前正在試驗@FixMethodOrder(MethodSorters.NAME_ASCENDING) –

相關問題