我們的項目包含2600個類文件 - 我們應該在哪裏開始編寫junit測試？

我們的項目包含2600個類文件，我們決定開始使用自動化測試。我們的項目包含2600個類文件 - 我們應該在哪裏開始編寫junit測試？

我們知道我們以前應該已經啓動了這個2599類文件，但是大型項目如何以及在哪裏開始編寫測試？

挑一個隨機課，然後去？

重要的是要知道什麼？有沒有好的工具可以使用？

來源

2010-09-27 corgrath

事實上，你應該已經開始2600課前。先寫單元測試。 – JeremyP 2010-09-27 13:06:41

這隻適用於TDD，並不是每個人都想這樣做。 – corgrath 2010-09-27 13:44:57

編寫一個單元測試，然後再改變某些東西，以及遇到的每個錯誤。

換句話說，測試你目前正在使用的功能。否則，要爲所有課程編寫測試需要花費大量的時間和精力。

來源

2010-09-27 12:09:55 Sjoerd

爲你遇到的每一個錯誤+1編寫一個演示bug的測試用例，然後進行修復，然後看看測試用例通過。 – 2010-09-30 02:43:32

開始爲提交的每個錯誤編寫測試（編寫測試，觀察失敗，修復錯誤，再次測試）。還要先測試新功能（它們更可能有錯誤）。它一開始會很慢，但隨着您的測試基礎架構的增長，它將變得更加容易。

如果你正在使用Java 5或更高，使用JUnit 4

瞭解的單元測試，集成測試和驗收測試的區別。也看看嘲笑。

來源

2010-09-27 12:10:36 Cephalopod

不要先嚐試單元測試。做系統測試（端對端測試），覆蓋大部分代碼。編寫所有新的代碼的單元測試。

這樣，您可以用系統迴歸測試來穩定舊代碼。隨着越來越多的新代碼進入代碼部分，單元測試開始消失。編寫單元測試舊代碼而不進行系統測試就會破壞代碼，並且由於代碼沒有考慮到可測試性而編寫代碼會很費事。

來源

2010-09-27 12:10:41 Arne

使用單元測試對舊代碼進行改造的另一種可能性是您編寫要通過的單元測試（因爲系統已經「正常工作」）並最終驗證不正確的行爲。 – 2010-09-27 13:14:49

@Mark Peters：恕我直言，這很好，在一個龐大的系統中，總會有人依靠不正確的行爲。通過編寫unittest以便它傳遞不正確的行爲，當你糾正不正確的行爲時，unittest可能會警告你該更改可能會影響其他人的代碼（然後是否決定是否打破向後兼容性的設計決定）。 – 2010-09-27 13:29:47

這是一個很好的謊言。你可以推遲找出什麼是「正確」和什麼是「錯誤」，直到需要做出改變。最好標記這些類型的測試，因爲單元測試通常應該*指定*正確的行爲，而不僅僅是防止功能改變。 – 2010-09-27 13:32:14

其他答案已經給出了有用的建議，但我錯過了一個清晰的基本原則闡述：力求最大化您的努力的好處。在很大程度上覆蓋單元測試的大型遺留代碼庫需要花費大量時間和精力。你想從一開始就把你努力的結果最大化。這不僅可以在早期提供有價值的反饋信息，還有助於說服/維持管理層和開發人員的支持，認爲這些努力是值得的。

所以