我已經爲我的項目的關鍵業務邏輯編寫了一些單元測試，並且我意識到TDD的概念和優缺點 - 我從來沒有真正走過「全部TDD的方式是「先編寫測試和東西。我目前正在開發一箇中等規模的項目，但我沒有自己開發這個項目，這非常可怕：沒有測試，緊密耦合的架構，沒有依賴注入，遺留的MVC框架等等 - 不太理想。我正在考慮從頭開始使用Laravel或Symfony，並應用TDD來真正實現鬆耦合和可測試的代碼。PHP：使用MVC應用程序進行測試驅動開發
我知道，僅僅通過這樣一個「大型」項目首先進入TDD可能不是一個好主意，所以我想我會做幾個測試項目來了解TDD如何影響我的代碼設計和質量。爲此，我們假設它只是某種具有用戶註冊和租用電影功能的「電影租賃應用程序」。我們還假設我已經做了一些UML圖，並且對所需的對象，它們之間的關係以及所需的業務邏輯有一些想法。
所以：從哪裏開始？在與使用MVC框架進行TDD的人交談時，有些人傾向於「孤立」業務邏輯功能，並開始接受測試，功能是「顯示可用電影列表」，測試如「導航到/電影和斷言一些HTML「或其他。對我來說，這並不是一個好的開始。個人而言，我喜歡從用戶登錄或用戶管理等功能入手 - 相當支持應用程序而不是業務邏輯本身的東西。如果我要使用這種方法，是不是會故意忽略我已經知道我需要的功能？讓我們假裝電影列表測試的作品，所以我會添加另一個測試，比如「OnlyLoggedInUserCanSeeMovieList」，看到它失敗並將邏輯添加到代碼中 - 即使在我編寫第一個測試之前，我也會需要這個邏輯。我很難相信這會導致更好的代碼，因爲我刻意不實現我已經知道的函數。
這是剛剛達到個人喜好還是有最佳做法讓我開始？你們如何在像Symfony或Laravel這樣的框架中開始使用TDD？在這種情況下做純TDD是否有點意義，因爲大量的應用程序邏輯已經被框架本身處理和測試過了？不要誤解我的意思：我不想再開始另一場關於TDD利弊的戰爭 - 我肯定有一些利益可以從我的頭腦中完全解決。儘管如此，現在這在相當簡單的功能上感覺像是一個微不足道的微觀進步，我覺得我會更好地測試應用程序邏輯的重要部分的單元，而不是做所有的「寫測試，看它失敗，編寫代碼，重構「迭代。
感謝一些投入，
克里斯