試圖學習TDD - 不太好

我一直在努力學習Python大約6周。在閱讀了很多有關TDD的網站之後，我購買了單元測試的藝術作者：Roy Osherove（偉大的書！），在嘗試使用TDD的同時學習Python。本書使用.NET，但它似乎不成問題。存根是存根，而嘲諷是嘲笑。試圖學習TDD - 不太好

當我在閱讀，並在網上看到TDD的例子時，我真的覺得我明白爲什麼編碼器會像他們那樣編寫代碼。但是，一旦我坐下來嘗試自己，我就無處可去。

讓我給你從昨天的例子：

我想嘗試TDD對於不那麼複雜的工程。基本上，我想要的是一個類，通過下載和解析RSS提要，保存包含（名稱，日期）的元組列表。我創建了一個新的PY文件爲我的測試中（沒有「真正的代碼」，但寫的），並寫了一個測試案例：

import unittest 

from tv_schedule import TvSchedule 

class TvScheduleTests(unittest.TestCase): 
    def test_download_success_and_parse_failure(self): 
     '''Successfully download RSS schedule for the specific user 
      but fail parsing it''' 
     self.tv = TvSchedule("User123") 
     # Check if ParserException was thrown I guess 


if __name__ == "__main__": 
    unittest.main()

...然後我有點卡住。我想（大聲笑！）。如果這只是愚蠢的和/或我如何能夠做得更好，我真的需要一些指示。我的直覺說我做了一些壞事。

我想讓TvSchedule類在後臺下載/解析（使用feedparser），所以您只需創建一個新的類實例，然後使用它。也許這是不好的設計，也使它很難測試？另外，我將如何消除通過網絡檢索RSS源的依賴性？通過對其進行存根並始終返回包含樣本Feed的內存字符串？

只要我離開TDD教程和書籍喜歡使用的真正簡單的計算器示例，我就會陷入困境。 :(

來源

2012-05-10 Rusty

我認爲在同一時間學習Python *和* TDD可能是一個壞主意。 TDD足夠複雜，無需添加新語言即可獲得這個組合:) –

請注意，「純粹」的TDD只有在您對代碼的去向有好的概念時纔有效。你可能想開始編寫足夠的代碼來確定你的想法，然後爲它寫一個測試（它應該擺脫你沒有解決的任何問題），然後修正你的代碼。 – Marcin

@ kigurai：可能是。我想我會嘗試。有些人似乎認爲在缺乏傳統思維的同時，更容易進入TDD思維模式。 – Rusty

您可能遇到的一個挑戰是您的測試過於寬泛。一次下載和解析意味着你會寫很多代碼。試着擠壓第一個測試。這可能有助於你給予一些關注。

另一個挑戰可能是您正在編寫沒有太多邏輯的代碼，您只是委託其他庫進行下載和RSS解析。這使得難以解決問題。在這種情況下，這可能是一個相當無趣的例子，試圖實踐。考慮嘗試像Conway's Game of Life那樣測試驅動器是一個有趣而簡單的問題。

希望有幫助！

布蘭登

來源

2012-05-10 14:42:33 bcarlso

由於feedparser在這種情況下幾乎處理所有事情，因此可能很難將任務委託給其他庫。在這種情況下，我覺得你的回答與我最爲共鳴，所以我會將你的答案標記爲已接受的答案。我會嘗試另一個問題，而不是這個。 – Rusty

這是我學習TDD的經驗。我從一個測試最終想要的行爲開始。然後意識到，在所有的小幫手類和功能都到位之前，測試永遠不會通過。所以，首先設計，然後在每個「模塊」上做TDD似乎是最好的方法。 –

我認爲你需要看看nose和mock。

nose是測試一個很好的模塊，它致意unittest好，並提供一個CLI命令來運行測試，並使用插件爲您提供有關的詳細信息您的測試平臺的結果（代碼覆蓋率等）

mock是我們存根或方式模擬方法或對象是對於像HTTP請求或對象的事情與服務的測試範圍之外的互動特別有用。

在你的榜樣，我會做你的饋線對象的某些補丁，並設置返回值，以你的一些邊緣案例和測試，以確保它與self.assertTrue正確處理案件，self.assertIsInstance（從unittest.TestCase繼承）等...

通常在使用nose和unittest時在python中執行TDD時，我首先使用setUp編寫TestCase的框架，有時使用tearDown來處理常見的模擬和存根。對於每種測試方法，我首先定義我所要做的，在unittest周圍設置環境，然後調用方法/對象並進行斷言。

在傳統的TDD中，您先設計測試，然後構建您的代碼以使測試變爲綠色。紅色 - >綠色。

來源

2012-05-10 14:04:36 lukecampbell

每當你在測試題目中有'和'，你正在測試兩件事情。一次測試一件東西要好得多，所以我建議你應該把你的測試重構成兩件。

其次，你想繼續在真正的小步驟。想想接下來可能做的最小的事情，那不適用於當前的代碼庫。

當你沒有代碼時，通常最小的可能是創建一個你的目標類的例子。不要要求它做任何事情，只要創建它。

這幾乎是你所處的情況。所以你做對了！

你的代碼不應該編譯，因爲沒有TvSchedule。 '不編譯'計爲紅色。編寫一些代碼來編譯它，這就是Green。好極了！

正如其他人所指出的，您應該在某處保留一點TODO列表。在Kent Beck的書中，他使用粘滯便箋。我喜歡在測試代碼文件中包含TODO列表。你待辦事項列表的範圍應該是你打算在你要花費半小時或兩小時之類的時間內完成的任務。不是一整天，從現在開始直到下一次休息。然後，在你的TODO列表中添加和減去一些東西。有助於你專注於做'下一步可能出錯的最簡單的事情'。

[編輯：添加待辦事項列表]

來源

2012-05-11 00:41:17 KarlM

試圖學習TDD - 不太好

回答

相關問題