# Who the hell are you TDD, DDD, BDD

## 前言
## fun fact
## 麻瓜解釋
TDD、BDD 和DDD 這三個縮寫在軟體開發中分別代表以下概念：

- TDD（Test-Driven Development） - 測試驅動開發：
TDD 是一種軟體開發過程，其中開發人員首先編寫一個小測試案例，然後編寫足夠的程式碼來使這個測試通過，最後重構新程式碼以滿足所需的設計標準。這個過程就是一個循環，被成為「紅-綠-重構」循環，其中測試先失敗（紅色），編寫程式碼使其通過（綠色），然後優化程式碼（重構）。 TDD 的焦點在於編寫乾淨的程式碼和降低未來的缺陷。

---
- BDD（Behavior-Driven Development） - 行為驅動開發：
BDD 將TDD 的基本思想和原則擴展到軟體的整個開發生命週期，但其著重點在於軟體的行為——即軟體應如何表現，而不僅僅是它應該完成什麼功能。 BDD 強調的是與利害關係人的溝通與協作，透過使用簡單易懂的語言來寫測試，讓非技術人員也能理解測試內容。 BDD 鼓勵團隊成員之間更好地溝通，確保所有人都對軟體應有的行為有共同的理解。
---
- DDD（Domain-Driven Design） - 領域驅動設計：
DDD 與TDD 和BDD 並不是同一類型的概念。 DDD 是一種軟體設計哲學，強調了在軟體專案的設計與開發中應以業務領域（Domain）為中心。它主張將業務領域的專業知識嵌入軟體的設計中，使軟體能更好地解決業務問題。 DDD 通常涉及豐富的領域模型以及分層的架構設計，以確保業務邏輯清晰且維護性高。

這三個概念在軟體開發中都扮演著重要的角色。 TDD 和BDD 都與確保軟體品質和滿足使用者需求有關，而DDD 則是一種更宏觀層面上對軟體設計的方法論。

---
- AAA (代表意思)
- Arrange（準備）：設定測試所需的狀態或數據。例如，準備測試數據、建立模擬對象或初始化測試環境。
- Act（執行）：執行測試的主要行為或操作，例如呼叫要測試的方法或觸發某個功能。
- Assert（驗證）：檢查結果是否符合預期，通常是用斷言（Assertions）來檢查是否達到測試的目標。

describe("test Q6", () => {
    test("test A", () => {
        //Arrange 準備要測試得題目
        const alphabet = ["abc", "abc", "cde", "abc"]
        //Act 執行要測試得fnc
        const result = Q6(alphabet)
        //Assert 驗證結果是否正確
        expect(result).toBe(`第一與第三個名子的奇數索引字母：["a","c"]["c","e"]`)
    })
})

這種模式的好處是簡潔，讓測試的流程清楚，尤其適合單元測試或功能測試，並且能幫助測試開發者保持測試的專注性和可讀性。

## 歷史

## 後記
個人總結：
- TDD 在於提升代碼品質，透過先測試失敗情況，在測試會通過情況，
## 參考
[單元測試中， TDD、BDD、DDD 分別指？ 【熱度: 166】 · Issue #742 · pro-collection/interview-question · GitHub](https://github.com/pro-collection/interview-question/issues/742)