What is Test-Driven Development (TDD)?

TDD Design Philosophy: Test-First

In traditional waterfall or agile development, developers are typically "write functional code first, then write tests when time permits", or even completely rely on manual testing (Test-Last).

TDD overturns this pattern.It treats "test scripts" as the concrete physical definition of requirements. Developers clarify boundary conditions, input/output specifications, and module interfaces by writing a test that is guaranteed to fail first; this ensures every line of code produced is solely to make tests pass, with no redundancy.

Development Mindset Showdown: Traditional Mode vs TDD Mode

Core Business Value Brought by TDD to Projects

TDD Real-World Case Study: MES Work Order Package Confirmation System

This case study uses the (MES) manufacturing execution system as a basis,"Work Order Package Verification"as the object for development using the TDD methodology. The system is responsible for checking whether all static configurations (CheckList, Route) and dynamic resources (BOM inventory, equipment status, critical parts) are fully in place before work orders go to production.

1. MES Package Verification Data Source (Excel Content Description)

The system will load two Excel spreadsheets from external sources as input data, with internal structure and test data as follows:

2. Test-driven code structure (TDD Tests Structure)

This system has four test files, using tests to drive feature development:

• 1. Domain model verification:test_models.py

  Defines and tests the most basic Python domain objects (Domain Entities). For example,WorkOrder、BOMItem 與 MaterialInventory, and ensures variable names, type hints (Type Hinting) such asiPlannedQty 與 sProductCodeare correct.

• 2. Parsing and mapping verification:test_loader.py

  Tests the program that reads Excel files. This test drives the development of a fault-tolerant mapping mechanism, allowing the program to use standard English spelling internally (such assMaterialId、sSerialNumber) but can automatically map when reading from Excel,compoents 與 serailfields with spelling errors.

• 3. Business logic verification:test_validator.py

  Tests core business rules. For example: the checklist must all beY; all corresponding equipment statuses for process steps areOK; and multi-batch inventory accumulation (summing quantities of the same material number across different batches, to confirm whether it is greater than or equal to計劃產量 * BOM用量）。

• 4. System integration verification:test_integration.py

  End-to-end testing (E2E Test). Calling the read module to load actualWO_validation.xlsx 與 inventory.xlsx, and loaded data is sent to validation engine; production quantity 5 passes intake successfully (returnTrue), production quantity 10 fails due to insufficient inventory (returnFalse）。

3. Demo presentation and test execution (run_demo.py)

We can use the dedicatedrun_demo.pyto execute comprehensive checks, and display operational results on the host terminal:

# 執行驗證引擎的單元測試
$ python -m unittest discover -s tests
....................
----------------------------------------------------------------------
Ran 20 tests in 0.320s
OK

# 執行實際的 Demo 展示程式
$ python run_demo.py
Loading data from Excel sheets...
Data loaded successfully.

--- Test Case 1: Planned Quantity = 5 ---
Expected: True, Actual Result: True

--- Test Case 2: Planned Quantity = 10 ---
Expected: False, Actual Result: False

3.5. Work order input and validation engine call relationship (run_demo.py and validator.py)

When we executerun_demo.pythe program will first accept the input work order information (such as work order production quantity), then call the comprehensive validation enginevalidator.pyin which rules verified by unit teststest_validator.pyfor comparison. Below is this core call fragment:

# 摘自 run_demo.py
# 1. 定義要校驗的工單計劃產量（例如輸入 5 與 10）
iQtySuccess: int = 5
iQtyFail: int = 10

# 2. 直接呼叫 validator.py 中定義的統一齊套校驗入口
# 該引擎背後運行的業務邏輯由 tests/test_validator.py 的測試用例保駕護航
bResultSuccess: bool = validate_work_order_kitting(
    iPlannedQty=iQtySuccess,
    lstBOM=lstBOM,
    lstRoute=lstRoute,
    lstChecklist=lstChecklist,
    lstCCRequirements=lstCCReq,
    lstMaterialInv=lstMaterialInv,
    lstEquipInv=lstEquipInv,
    lstCCInv=lstCCInv
)

Note:This process demonstrates the execution of program (run_demo.py) and TDD development outcomes cooperation. Inrun_demo.pyafter setting input conditions, directly callvalidator.py. Since all core logic within this validator has already been thoroughly verified in unit teststest_validator.py(multi-batch inventory accumulation, each status as OK, etc.), we can directly trust its results in the Demo.

4. Domain entity and validation logic interaction code (using test_validator.py as an example)

In TDD development, we use unit tests to first define the interaction between domain models and validation logic. Below excerpted fromtests/test_validator.pyunit test fragment for validating BOM inventory:

# 摘自 tests/test_validator.py
from src.domain.models import BOMItem, MaterialInventory
from src.domain.validator import validate_bom_inventory

def test_bom_inventory_sufficient_should_pass(self) -> None:
    # Arrange - 定義工單產量、BOM用量需求（使用由 models.py 定義之領域實體）
    iPlannedQty: int = 10
    lstBOM: list[BOMItem] = [
        BOMItem(sParentProduct="PRD-001", sMaterialId="A", dUsage=0.5, sUnit="kg"),
        BOMItem(sParentProduct="PRD-001", sMaterialId="B", dUsage=2.0, sUnit="kg")
    ]
    # 定義模擬的庫存狀況（由 MaterialInventory 實體組成）
    lstInventory: list[MaterialInventory] = [
        MaterialInventory(sMaterialId="A", sBatchId="a1", dAmount=3.0),
        MaterialInventory(sMaterialId="A", sBatchId="a2", dAmount=3.0),
        MaterialInventory(sMaterialId="B", sBatchId="b1", dAmount=15.0),
        MaterialInventory(sMaterialId="B", sBatchId="b2", dAmount=10.0)
    ]
    
    # Act - 呼叫待測試的驗證邏輯
    bIsBOMOk: bool = validate_bom_inventory(
        iPlannedQty=iPlannedQty,
        lstBOM=lstBOM,
        lstInventory=lstInventory
    )
    
    # Assert - 斷言驗證結果符合預期 (必須為 True)
    self.assertTrue(bIsBOMOk)

Note:This fragment demonstrates how the test program actively instantiates inmodels.pydefined data structures, and passes them as parameters tovalidator.pyfunction for validation. When writing this test,validate_bom_inventorydid not yet exist (or only had a stub returning False), which forced developers to first establish the function's parameter interface and types before writing actual code.

5. Integration and Excel loading verification code (using test_integration.py as an example)

In E2E integration tests or demonstration scripts, we useloader.pyto read actual Excel files, and pass the parsed data list into the integrated comprehensive validation engine. Below excerpted fromtests/test_integration.pyTest snippet:

# 摘自 tests/test_integration.py
from src.domain.loader import (
    load_bom_items, load_route_steps, load_checklist_items,
    load_critical_component_requirements, load_material_inventories,
    load_equipment_inventories, load_critical_component_inventories
)
from src.domain.validator import validate_work_order_kitting

class TestWorkOrderKittingIntegration(unittest.TestCase):
    def setUp(self) -> None:
        self.sValidationPath: str = r"c:\AI\Antigravity\anti\TDD_method\TDD\WO_validation.xlsx"
        self.sInventoryPath: str = r"c:\AI\Antigravity\anti\TDD_method\TDD\inventory.xlsx"

        # 1. 透過 loader 載入實體 Excel 數據，並由 loader 完成欄位拼寫轉換
        self.lstBOM = load_bom_items(self.sValidationPath)
        self.lstRoute = load_route_steps(self.sValidationPath)
        self.lstChecklist = load_checklist_items(self.sValidationPath)
        self.lstCCReq = load_critical_component_requirements(self.sValidationPath)
        self.lstMaterialInv = load_material_inventories(self.sInventoryPath)
        self.lstEquipInv = load_equipment_inventories(self.sInventoryPath)
        self.lstCCInv = load_critical_component_inventories(self.sInventoryPath)

    def test_e2e_sufficient_inventory_should_pass(self) -> None:
        # Arrange - 設定計劃生產量為 5 (根據 Excel，此產量庫存足夠)
        iPlannedQty: int = 5

        # Act - 呼叫單一入口齊套校驗函式
        bIsKittingComplete: bool = validate_work_order_kitting(
            iPlannedQty=iPlannedQty,
            lstBOM=self.lstBOM,
            lstRoute=self.lstRoute,
            lstChecklist=self.lstChecklist,
            lstCCRequirements=self.lstCCReq,
            lstMaterialInv=self.lstMaterialInv,
            lstEquipInv=self.lstEquipInv,
            lstCCInv=self.lstCCInv
        )

        # Assert - 驗證結果應為 True (齊套通過)
        self.assertTrue(bIsKittingComplete)

illustrate:This integration test snippet showsloader.py 與 validator.pyfull collaboration. Loader is responsible for parsing out theBOMItem、RouteStepand other entity lists, and perfectly absorbs Excel such ascompoents、serailWait for spelling errors so that Validator can use standard English field naming to complete business rule judgments cleanly and decoupled.

6. System interaction and TDD mental diagram (Interaction & TDD Loop)

The following figure shows the interaction between the Excel file, loader, domain model, verification engine and test code (including Demo), as well as the Red-Green-Refactor cycle spirit followed by the TDD methodology:

illustrate:When the system is operating,run_demo.py(or integration test) driverloader.pyRead and convertExcelarchive, generatemodels.pyDomain model entities defined in thevalidator.pyThe inspection will be carried out and the final confirmation results will be sent back. In the development process, the TDD cycle of "red (failed test) $\rightarrow$ green (minimum implementation) $\rightarrow$ reconstruction (architecture optimization)" is always followed.