與工作端代碼一起創建的數據集定期包含業務基本原理的戰略部分。SQL是代碼。你應該盡早批準它，而且要徹底批準。

測試金字塔是有助于描述編程測試特征的一種顯著表示形式。當您逐步實現更值得注意的段協調時，您將繼續從許多確定的、快速的和非接觸的測試，轉向總體上批準框架的越來越慢的全球測試。這在基本層面上是個好兆頭，但是很難澄清單元測試、連接測試和開始到完成測試之間的分離應該如何工作。

結論：在金字塔的哪一層，哪一部分要協調進行對比。您可能會認為數據集在上層有一席之地，因為它的設置和運行成本很高。然而，當它包含需要逐項批準的業務基本原理時，在金字塔中較低的確定階段協調它也是一個好兆頭。它經常需要那種徹底的批準，你不能把它留給幾次溫和的全球合并測試。然而，我們應該先回顧一下單元測試的含義。

速度、單焦點和隔離

在VladimirKhorikov的《單元測試原理、實踐和模式》一書中，單元測試的三個必要條件是速度、單中心和斷開連接——如果測試不依賴于彼此的狀態，它們可以平等運行。單一中心只能找到：作為一個單獨的行為單位，而不是一個行為單位。主要方法支持——事實上是請求——被測試類和測試類之間的嚴格對應，而隨后的方法以公共API為中心，基本上不擔心批準執行細節。代碼單元方法希望您通過使用測試副本(derides和釘子)刪除被測試類外部的任何部分。這當然適用于與信息庫的所有連接。行為單位法更冷靜，當使用真品會降低執行力時，可能會使用測試對。

在檢查信息庫之前，應該先研究一個模型，在這個模型中，協調單元測試中的彈簧設置是個好兆頭。想想這個基本的休息調節器：

假設我們需要批準管理員客戶端獲得HTTP200響應，非管理員客戶端獲得401響應。為了測試這一點，我們需要打開一個Spring設置，它不難完成，但比普通的單元測試要慢。這是一個組合測試嗎?然而，從專業的角度來看，確實，一個特別細粒度的測試具有單元測試的每一個特征。此外，沒有Spring設置的普通單元測試無法以任何方式、形狀或形式批準預授權解釋中捕獲的業務規則。

回到我們的主題：為數據集代碼編寫相對細粒度的測試是否有利?與使用Spring運行時相比，創建一個類似信息庫的庫要昂貴得多。這里有一個基本原則來幫助你確定這個選擇。一個逐項測試，作為普通形式的一個特性在本地運行，如果有合理的可能性，它可以預防正在進行的基本錯誤，那么它將始終是有利的。

考慮到我們的批準測試，適當的回答將是“是”。設置錯誤很容易逃過所有人的注意，并導致重大安全泄漏。通過您自己的努力，提前測試以防止以后的復發對于所有基本的非無關緊要的代碼來說都是必須的。集團外部提供并保持的資產條件是另一種情況。你可以更有效地讓他們進入從開始到結束的階段，因為在你的鄰居機器上模仿局外人框架通常不會讓事情變得糟糕。盡管如此，這些情況并不構成大多數情況。

如果有合理的可能性，逐點測試始終是有利的，它可以預防正在進行的基本錯誤。

SQL是代碼

從系統管理和組織的角度來看，您的信息庫可能類似于外部依賴，但是，當它與使用它的代碼一起創建時，它絕不是您正在構建的框架的一個重要部分。SQL是代碼。它闡述了重要的業務原理。它可以將信息庫工作者作為透視圖、觸發器和存放技術，也可以將自己顯示為散落在控制代碼中的SQL問題，或者狡猾地隱藏在Hibernate標準標點符號中。但是，從長遠來看，它是由信息庫工作人員破譯的，最好是在代碼移動到客戶端確認環境之前。

與Java相比，信息庫驅動的風險投資應用程序中的SQL代碼是獨一無二的。這絕不是一個解釋性的編程模型，它本質上是有狀態的和頑強的。承認測試不是一個客戶驅動的小黃瓜情境，30個問題的結果是一個非常困難的問題。問題的成敗通常取決于數據集的早期條件。當測試不能完全控制此狀態時，信息庫測試變得異想天開。被測單元越溫和，控制這種狀態就越簡單。

在最后一節中，Psyche也是一個被破譯的詞。雖然Oracle的put-away方法不可能包含語言結構錯誤，但Java中粗糙的SQL在數據集上運行時可能會出錯。真相終究會揭曉的，所以快吃吧，不要當甜點。

總而言之，沒有什么比不徹底測試您的信息庫關聯更糟糕的了。事實上，我們需要擴展單元測試的含義，以包含運行成本更高的測試，這使得真正的測試能夠將一般形式的時間保持在令人滿意的范圍內。您可以使用的一些技術和系統將在后面的文章中討論，但是，現在讓我總結一下：

組織代碼的技巧

千萬不要把粗糙的SQL和控制原理放在一起。從理論上講，這些關聯隱藏在接口后面，并在測試期間偽造信息庫通信。不直接引用SQL的代碼不需要依賴運行中的信息庫進行測試，并且它不應該對組名中包含SQL的任何內容設置時間條件。

將上面描述的數據集通信的執行放在提交類中，每種技術有一個問題。在這種粒度級別上，編寫逐點測試將表格帶到理想狀態并批準結果要簡單得多。

如果您有許多信息基礎測試覆蓋了許多大綱，請考慮將數據集代碼分離成每個模式的獨立模塊，并使用它們自己的生成和交付。這樣，您只需要形成并測試受影響的模塊。為了實現這一點，這些模塊應該是近似耦合的，模式之間的條件不重要。

運行/維護測試數據庫的分步說明

在類似的計算機上運行信息庫的容器化格式副本。記憶很重要。表單交互處理的是創建和銷毀持有者，任何測試套件都不能使數據集處于骯臟的狀態。

為了避免對每一個試驗做任何準備，請考慮從附近的商店提供一個尖端的復制品，未填寫或有限制的測試信息。限制此設備信息的測量。一切都增加了維護負擔，而且你還沒有進行展覽測試。