Ý tưởng rằng TDD có hại cho thiết kế và kiến trúc không mới mẻ gì. DHH (David Heinemeier Hansson) đã đề xuất cách đây vài năm khái niệm Test Induced Design Damage; trong đó ông so sánh thiết kế mà ông thích với một thiết kế do Jim Weirich tạo ra, đó là “có thể kiểm chứng được”. Tham số, chung quy là chia tách và gián đoạn. Khái niệm thiết kế tốt của DHH giảm thiểu các thuộc tính này, trong khi Weirich tối đa chúng.

Vẫn còn một tranh luận phổ biến khác là khi số lượng các kiểm thử tăng lên, một thay đổi đơn lẻ đối với mã sản xuất có thể khiến hàng trăm kiểm thử để yêu cầu các thay đổi tương ứng. Ví dụ, nếu bạn thêm một đối số nào vào một phương thức, mọi kiểm thử với phương thức đó phải được thay đổi để bổ sung thêm đối số mới. Điều này được gọi là The Fragile Test Problem (Vấn đề với Kiểm thử Mong manh).

Một tranh luận liên quan là: Bạn càng có nhiều kiểm thử, việc thay đổi mã sản xuất càng khó khăn; bởi vì rất nhiều bài kiểm thử có thể bị hỏng và đòi hỏi phải chỉnh sửa. Vì vậy, các kiểm thử làm cho mã sản xuất trở nên cứng nhắc.

còn tiếp…

HÃY LIÊN HỆ VỚI CHÚNG TÔI ĐỂ NHẬN THÔNG TIN ĐẦY ĐỦ VỀ BÀI VIẾT

    Tên của bạn (*)

    Địa chỉ Email (*)

    Số điện thoại

    Công ty

    Chức vụ

    HÃY BẮT TAY VỚI CHÚNG TÔI ĐỂ BẮT ĐẦU HÀNH TRÌNH AGILE

    Related Posts
    Chàng kỹ sư trẻ

    Tôi muốn lãnh đạo một nhóm và có thể đưa ra những quyết định quan trọng về cơ sở dữ Read more

     Flaccid Scrum

    Những gì đã xảy ra là họ đã thiếu sự đầu tư cho chất lượng tự thân của phần mềm Read more

    6 hiểu nhầm về DevOps cần tránh

    Chúng ta rất hứng khởi về sự phát triển của DevOps. Nhưng khi việc ứng dụng tăng lên, sẽ có Read more

    6 bước giúp bạn sống sót qua quá trình chuyển đổi DevOps

    DevOps có ở mọi nơi và nếu bạn không phải đang ở giai đoạn giữa của một chương trình chuyển Read more