單元測試數據庫方法

Question

我即將為新的Web應用程序編寫單元測試。

我首選的方法是測試實時數據庫結構而不是內存數據庫。

據我所知，我可以將我的單元測試數據庫調用包含在未提交的事務中。

我認為更好的方法是在初始化測試之前復制實時數據庫，並允許事務提交到測試數據庫。 如果測試以正確的順序運行，這將允許我通過注冊第一個帳戶，通過各種交互，以帳戶關閉結束來創建完整的測試故事。 即現實世界的生命周期。 我確信這應該是一個很好的方法，但從未將其付諸實踐，但我想知道在我繼續之前人們是否嘗試過類似的方法和反饋意見。 提前致謝。

Answer 1

我知道我會通過這樣做成為那個人 ，但是讓我們在此之前建立我們的條款。 如果您只關心答案，請跳過此部分。

---

單元測試應該只測試一個單元。 它不應該依賴於外部依賴項，例如數據庫，Web服務或文件系統。 相反，應該模擬這些依賴關系，以便可以精確控制每個單獨測試的狀態。

單元測試應該是原子的，一致的和可重復的。 正如John指出的那樣，測試應該能夠自己運行，或者每次都在具有完全相同行為的套件中運行。

集成測試應測試組成系統的各個單元之間的交互。 因此，他們永遠不應該尋求存根或模擬任何依賴。 這些測試應該盡可能接近測試可以實現的部署到生產的測試。

---

讓我第一個告訴你，雖然集成測試依賴於設置和拆卸是很常見的，但在這個舞台上輕輕一點 。

當然，開始時似乎是一個非常好的主意，但出於同樣的原因，程序代碼通常最終會成為維護的噩夢，程序測試甚至更糟。 由於它們與底層代碼的實現細節緊密耦合，因此如果您更改了這些細節，最終將不得不更改大量測試。

在最好的情況下，您將丟棄大量測試並重新開始。 在最糟糕的情況下，你會毫不猶豫地重構你的系統，因為你不想打破你的測試......從而剝奪了你應該帶來的優勢。

我能給你的最好建議是開始閱讀驗收測試和行為驅動開發 。

有些人可以提供幫助：

Gojko Adzic ， Bob Martin

一些可以提供幫助的工具：

FitNesse ， SpecFlow ， 黃瓜

請！ 請！ 請！ 閱讀並向這些人和那些社區學習。 他們將引導您朝着正確的方向前進，並幫助您避免自動化測試的長期問題。

Answer 2

單元測試不應該依賴於它們的順序，也不應該取決於測試的狀態。 他們應該建立所有必要的狀態。

你所描述的可能是一個有用的測試，但它不是一組單元測試。