我目前正在嘗試使用PHPUnit來了解測試驅動開發（TDD），並且有關於使用TDD編寫報告的問題。使用TDD創建報告
第一關：我明白TDD的基本過程：
但我的問題是：你如何使用TDD寫報告？假設你的任務是編寫一份報告，說明按照顏色，類型和體重通過給定十字路口的汽車數量。現在，所有上述數據都已被捕獲到數據庫表中，但您被要求關聯它。
你如何去寫一個你不知道結果的方法的測試？根據用戶在運行報告時可能提供的日期範圍和其他限制條件，關聯此數據的方法的結果將會發生變化？在這種情況下，您如何使用像PHPUnit這樣的框架在TDD的範圍內工作？
您可以預先創建測試數據，它代表您將在生產中收到的數據類型，然後測試代碼，每次運行測試（即在SetUp（）函數中）刷新表格。
無論您測試的是什麼，您都無法根據您在生產中收到的實際數據進行測試。您只是測試代碼按照給定方案的預期工作。例如，如果您將測試表加載五排藍色汽車，那麼您希望報告在測試時顯示五輛藍色汽車。您正在測試報告的各個部分，以便完成後您將自動測試整個報告。
作爲比較，如果您正在測試的函數需要1到100之間的正整數，您會編寫100個測試來測試每個單獨的整數嗎？不，你會在範圍內測試某些東西，然後測試邊界上和周圍的東西（例如-1,0,1,50,99,100和101）。例如，您不測試55，因爲該測試將沿着與50相同的代碼路徑進行測試。
確定您的代碼路徑和要求，然後爲其中的每一個創建合適的測試。您的測試將成爲您的要求的反映。如果測試通過，那麼代碼將準確地表達您的需求（如果您的需求錯誤，TDD無法爲您節省）。
運行測試套件和運行腳本時，不要使用相同的數據。您使用測試數據。所以如果你想與數據庫交互，一個好的解決方案是創建一個sqlite database stored in your ram。
同樣，如果你的函數與文件系統交互，你可以使用a virtual filesystem。
而且如果你必須與對象交互，you can mock them too。
好的是你可以測試你在編寫代碼時所考慮的所有惡性邊緣情況數據（嘿，如果數據包含未轉義的引號？）。
直接對您的生產服務器進行測試非常困難，而且通常是不明智的，所以最好的辦法就是假冒它。
首先，創建一個stub，這是一個特殊的對象，它代表數據庫允許您進行單元測試，假設某個值來自數據庫，當它真的來自您時。如果需要，你有一些能夠產生一些你不知道的東西，但仍然可以通過測試。
一旦一切都在那裏工作，你可以在數據庫本身的數據集在一些測試模式 - 基本上，你，但使用不同的參數連接，以便當它認爲它正在尋找PRODUCTION.CAR_TABLE它真正關注的TESTING.CAR_TABLE 。你甚至可能希望每次都進行測試刪除/創建表（儘管這可能會有點多，但它會產生更可靠的測試）。