如何組織實時數據完整性測試和代碼單元測試？

Question

我有幾個帶代碼測試代碼的文件（使用“unittest”類）。

后來我發現測試數據庫完整性也很好。 我把它放到一個單獨的目錄樹中。 （像鍵的格式正確，父節點和子節點指向正確等等。編輯：這是一個nosql項目，我不能依賴數據庫級別檢查謊言參照完整性等。）

我使用相同的unittest類進行完整性測試。

現在我想知道保持這種分離是否真的有意義。 為了測試數據的完整性，我經常復制用於測試處理數據的代碼的代碼部分。

但它不一樣。 代碼測試使用測試數據庫（在每次測試后刪除），完整性測試連接到實時數據並進行分析。 我想從cron調用的完整性測試，如果實時數據庫中發生了某些事情，則發送警報。

你會怎么處理？ 這樣的設置有標准嗎？ 你有什么經歷？

我傾向於將所有內容放在同一個文件中，這將導致代碼測試也由生產環境中的cron執行。

編輯：推動我的是，嘗試保持項目簡單，不要讓單個任務或工作流程觸及太多文件。 沒有所有的測試，我已經有了一個類文件，一個子類，一個相關的類，一些庫（幫助器）文件和主代碼。 測試添加一個文件。 它有助於我在編碼時保持注意力集中，壓力更小，我相信我減少了錯誤，我可以更快地記住並找到一個特定代碼部分，減少受影響的文件。 每個工作流程只有一個測試文件可以幫到這里 如果我保持它是單獨的，有2個文件（數據完整性測試和代碼測試），也許3個（兩者的公共庫）。 抽象會增加復雜性。

編輯2：我現在正在重構一點，只將數據測試文件移動到同樣的目錄樹中，代碼測試也存在於同一目錄樹中，但保留名稱為“完整性”或“測試”的不同文件。 我不會（還）合並這些文件，因為2個人建議反對它，我相信他們現在的經驗和建議。 我現在將使用代碼重復。

編輯3：我忘了提到每次運行的測試選擇不是由這種情況下的樹結構決定的。 測試在主文件中枚舉，因此我目前有2個主文件“完整性”和“代碼測試”，並且測試可以存在於相同的直接結構中。

也許會有更多人回答。 到目前為止，感謝您提供寶貴的意見，這已經幫助我開發了最終的結構！

Edit4：我現在做了更多的重構。 我似乎應該保留2個文件，但目的略有修改。 一個針對生產服務器上的計划監視。 另一個用於開發。 但在這兩個文件中都可以進行完整性測試或代碼測試。 在兩個文件中，可以在測試數據庫（在測試之后擦除）和永久數據庫（每個都有永久數據庫，生產服務器和開發服務器）上執行操作。 還有一件重要的事情：我發現自己將大量常用代碼從測試文件移到了類文件中。 所以這些課程也獲得了僅用於測試的能力。 到目前為止我喜歡這個，感覺很干凈。 我還沒有（還）創建一個在兩個測試前端之間共享的測試庫，這段代碼已經轉到了現在正在考慮的obejct的類文件中。

請注意，我在下面的評論是用“user89021”簽名的，但是我是karlthorwald。 我無能為力。

Answer 1

你分離它們的方法很好。

您對代碼重復的關注是100％有效。

解決方案是相當直接的 - 將測試之間的常見功能 - 例如“RunTest”，“AnalyzeResult”，“ConnectToDB” - 抽象到一個公共庫（你沒有指定哪種語言，但我認為它有一個庫的概念）可以傳遞匯總詳細信息，例如要連接到哪個數據庫。

然后獨立於單元測試驅動程序和完整性測試驅動程序使用該庫 - 如果您熟練/幸運的話，除了配置之外可能只有很少的代碼（例如，要連接到哪個數據庫，如何報告結果，以及哪個測試運行）。

同樣，如果需要，可以將公共輸入/數據集放在公共目錄中

Answer 2

您應該將數據庫相關測試與“純”單元測試分開。
考慮到好處，擁有兩個不同程序集的成本非常低 - 您可以在任何計算機上運行一套快速，無需環境設置的測試，以及測試只能在特定位置運行的數據庫完整性的較慢套件（例如構建服務器）。

另一個好處是，您可以擁有兩個運行不同測試套件的構建過程（快速和夜間）。

為避免重復代碼，您可以使用兩個測試套件所需的常用方法/操作創建另一個程序集。 不要過分擔心重復實際測試，因為你正在測試不同的東西（邏輯或數據庫），所以你的測試遲早會根據你要測試的內容而變得非常不同。

Answer 3

還有一個答案。 您有兩種類型的測試。 我想做的是解決完整性測試。 您可能想要做的是將完整性測試作為生產代碼的函數。 IOW，將完整性作為系統的一部分。

您已經提到重復是一個問題，並且您正在重構以刪除重復。 重構的代碼當然有開發測試嗎？

系統監控可以是生產代碼。 因此，您編寫的代碼將成為系統的一部分。

關於這一點的好處是你通過開發測試改進了代碼。