TDD có thực sự làm việc cho các dự án phức tạp không?

Tôi đang hỏi câu hỏi này liên quan đến các vấn đề tôi gặp phải trong các dự án TDD. Tôi đã nhận thấy những thách thức sau đây khi tạo bài kiểm tra đơn vị.

• Tạo và duy trì dữ liệu giả

Thật khó và không thực tế để duy trì dữ liệu giả lớn. Nó thậm chí còn khó hơn khi cấu trúc cơ sở dữ liệu trải qua những thay đổi.

• GUI kiểm tra

Ngay cả với MVVM và khả năng kiểm tra GUI, phải mất rất nhiều mã để tạo lại kịch bản GUI.

• Thử nghiệm kinh doanh

Tôi có kinh nghiệm rằng TDD hoạt động tốt nếu bạn giới hạn nó theo logic kinh doanh đơn giản. Tuy nhiên logic kinh doanh phức tạp rất khó kiểm tra vì số lượng kết hợp các thử nghiệm (không gian thử nghiệm) là rất lớn.

• Mâu thuẫn trong yêu cầu

Trong thực tế, thật khó để nắm bắt tất cả các yêu cầu được phân tích và thiết kế. Nhiều lần một yêu cầu lưu ý dẫn đến mâu thuẫn vì dự án phức tạp. Sự mâu thuẫn được tìm thấy muộn trong giai đoạn thực hiện. TDD yêu cầu các yêu cầu là chính xác 100%. Trong những trường hợp như vậy, người ta có thể mong đợi rằng các yêu cầu xung đột sẽ được nắm bắt trong quá trình tạo các bài kiểm tra. Nhưng vấn đề là đây không phải là trường hợp phức tạp.

Tôi đã đọc câu hỏi này: Tại sao TDD hoạt động?

TDD có thực sự làm việc cho các dự án doanh nghiệp phức tạp không, hay thực tế nó có giới hạn đối với loại dự án không?

Thật khó và không thực tế để duy trì dữ liệu giả lớn. Nó thậm chí còn khó hơn khi cấu trúc cơ sở dữ liệu trải qua những thay đổi.

Sai trái.

Kiểm tra đơn vị không yêu cầu dữ liệu giả "lớn". Nó đòi hỏi đủ dữ liệu giả để kiểm tra các kịch bản và không có gì hơn.

Ngoài ra, các lập trình viên thực sự lười biếng yêu cầu các chuyên gia về vấn đề tạo ra các bảng tính đơn giản của các trường hợp thử nghiệm khác nhau. Chỉ là một bảng tính đơn giản.

Sau đó, lập trình viên lười biếng viết một tập lệnh đơn giản để chuyển đổi các hàng bảng tính thành các trường hợp kiểm thử đơn vị. Nó khá đơn giản, thực sự.

Khi sản phẩm phát triển, bảng tính của các trường hợp thử nghiệm được cập nhật và các thử nghiệm đơn vị mới được tạo. Do đó tất cả các thời gian. Nó thật sự có hiệu quả.

Ngay cả với MVVM và khả năng kiểm tra GUI, cũng cần rất nhiều mã để tạo lại kịch bản GUI.

Gì? "Tái sản xuất"?

Quan điểm của TDD là Thiết kế mọi thứ cho Khả năng kiểm tra (Phát triển ổ đĩa thử nghiệm). Nếu GUI phức tạp, thì nó phải được thiết kế lại để đơn giản hơn và dễ kiểm tra hơn. Đơn giản hơn cũng có nghĩa là nhanh hơn, dễ bảo trì hơn và linh hoạt hơn. Nhưng chủ yếu là đơn giản hơn sẽ có nghĩa là dễ kiểm tra hơn.

Tôi có kinh nghiệm rằng TDD hoạt động tốt nếu bạn giới hạn nó theo logic kinh doanh đơn giản. Tuy nhiên logic kinh doanh phức tạp rất khó kiểm tra vì số lượng kết hợp kiểm tra (không gian kiểm tra) là rất lớn.

Điều đó có thể đúng.

Tuy nhiên, yêu cầu các chuyên gia về vấn đề cung cấp các trường hợp thử nghiệm cốt lõi ở dạng đơn giản (như bảng tính) thực sự có ích.

Các bảng tính có thể trở nên khá lớn. Nhưng không sao, vì tôi đã sử dụng một tập lệnh Python đơn giản để biến các bảng tính thành các trường hợp thử nghiệm.

Và. Tôi đã phải viết một số trường hợp thử nghiệm bằng tay vì các bảng tính không đầy đủ.

Tuy nhiên. Khi người dùng báo cáo "lỗi", tôi chỉ cần hỏi trường hợp kiểm tra nào trong bảng tính là sai.

Tại thời điểm đó, các chuyên gia về chủ đề sẽ sửa bảng tính hoặc họ sẽ thêm các ví dụ để giải thích những gì sẽ xảy ra. Các báo cáo lỗi có thể - trong nhiều trường hợp - được xác định rõ ràng là một vấn đề trường hợp thử nghiệm. Thật vậy, từ kinh nghiệm của tôi, việc xác định lỗi là một trường hợp thử nghiệm bị hỏng làm cho cuộc thảo luận trở nên đơn giản hơn nhiều.

Thay vì lắng nghe các chuyên gia cố gắng giải thích một quy trình kinh doanh siêu phức tạp, các chuyên gia phải đưa ra các ví dụ cụ thể về quy trình.

TDD yêu cầu các yêu cầu là chính xác 100%. Trong những trường hợp như vậy, người ta có thể mong đợi rằng các yêu cầu xung đột sẽ được nắm bắt trong quá trình tạo các bài kiểm tra. Nhưng vấn đề là đây không phải là trường hợp phức tạp.

Không sử dụng TDD hoàn toàn bắt buộc các yêu cầu phải chính xác 100%. Một số người cho rằng TDD có thể chấp nhận các yêu cầu không đầy đủ và thay đổi, trong đó cách tiếp cận không TDD không thể hoạt động với các yêu cầu không đầy đủ.

Nếu bạn không sử dụng TDD, mâu thuẫn được tìm thấy muộn trong giai đoạn thực hiện.

Nếu bạn sử dụng TDD, mâu thuẫn được tìm thấy trước đó khi mã vượt qua một số thử nghiệm và thất bại các thử nghiệm khác. Thật vậy, TDD cung cấp cho bạn bằng chứng về sự mâu thuẫn sớm hơn trong quy trình, rất lâu trước khi thực hiện (và các đối số trong quá trình kiểm tra chấp nhận của người dùng).

Bạn có mã vượt qua một số bài kiểm tra và thất bại những người khác. Bạn nhìn vào chỉ những kiểm tra và bạn tìm thấy những mâu thuẫn. Nó hoạt động thực sự, thực sự tốt trong thực tế bởi vì bây giờ người dùng phải tranh luận về mâu thuẫn và đưa ra các ví dụ cụ thể, nhất quán về hành vi mong muốn.

Đúng

Lần tiếp xúc đầu tiên của tôi với TDD là làm việc trên các thành phần phần mềm trung gian cho điện thoại di động dựa trên Linux. Cuối cùng, điều đó đã tạo ra hàng triệu dòng mã nguồn, lần lượt được gọi là khoảng 9 gigabyte mã nguồn cho các thành phần nguồn mở khác nhau.

Tất cả các tác giả thành phần dự kiến ​​sẽ đề xuất cả API và một bộ các bài kiểm tra đơn vị và được họ xem xét thiết kế bởi một ủy ban ngang hàng. Không ai mong đợi sự hoàn hảo trong thử nghiệm, nhưng tất cả các chức năng tiếp xúc công khai phải có ít nhất một thử nghiệm và một khi một thành phần được gửi tới kiểm soát nguồn, tất cả các thử nghiệm đơn vị phải luôn vượt qua (ngay cả khi chúng làm như vậy vì thành phần đó đã báo cáo sai nó hoạt động ổn).

Không còn nghi ngờ gì nữa, ít nhất là một phần do TDD và một sự khăng khăng rằng tất cả các bài kiểm tra đơn vị luôn vượt qua, phiên bản 1.0 xuất hiện sớm, dưới ngân sách và với sự ổn định đáng kinh ngạc.

Sau khi phát hành 1.0, vì công ty muốn có thể nhanh chóng thay đổi phạm vi do nhu cầu của khách hàng, họ đã nói với chúng tôi bỏ việc làm TDD và loại bỏ yêu cầu mà các bài kiểm tra đơn vị vượt qua. Thật đáng ngạc nhiên khi chất lượng đi xuống nhà vệ sinh nhanh chóng, và sau đó lịch trình theo sau nó.

Tôi cho rằng dự án càng phức tạp, bạn càng nhận được nhiều lợi ích từ TDD. Những lợi ích chính là tác dụng phụ của việc TDD sẽ buộc bạn viết mã theo các phần nhỏ hơn, độc lập hơn nhiều. Những lợi ích chính là:

a) Bạn nhận được xác nhận sớm hơn nhiều về thiết kế của mình vì vòng phản hồi của bạn chặt chẽ hơn nhiều do các thử nghiệm từ việc di chuyển.

b) Bạn có thể thay đổi bit và miếng và xem hệ thống phản ứng như thế nào vì bạn đã xây dựng một phạm vi bảo hiểm toàn bộ thời gian.

c) Kết quả là mã sẽ tốt hơn nhiều.

TDD có thực sự làm việc cho các dự án phức tạp không?
Đúng. Không phải mọi dự án vì vậy tôi được bảo là hoạt động tốt với TDD, nhưng hầu hết các ứng dụng kinh doanh đều ổn và tôi cá là những ứng dụng không hoạt động tốt khi chúng được viết theo cách TDD thuần túy có thể được viết theo cách ATDD mà không gặp vấn đề gì lớn.

Tạo và duy trì dữ liệu giả
Hãy giữ cho nó nhỏ và chỉ có những gì bạn cần và đây không phải là vấn đề đáng sợ. Đừng hiểu lầm tôi, đó là một nỗi đau. Nhưng nó đáng giá.

Kiểm tra GUI
Kiểm tra MVVM và đảm bảo rằng có thể được kiểm tra mà không cần xem. Tôi thấy điều này không khó hơn kiểm tra bất kỳ logic kinh doanh nào khác. Kiểm tra chế độ xem trong mã tôi không làm, tất cả những gì bạn đang kiểm tra tuy nhiên tại thời điểm này là logic ràng buộc, điều mà người ta hy vọng sẽ được nắm bắt nhanh chóng khi bạn thực hiện kiểm tra thủ công nhanh.

Kiểm tra doanh nghiệp
Không tìm thấy là một vấn đề. Rất nhiều bài kiểm tra nhỏ. Như tôi đã nói ở trên, một số trường hợp (người giải câu đố Sudoku dường như là một trường hợp phổ biến) rõ ràng là khó thực hiện TDD.

TDD yêu cầu các yêu cầu là chính xác 100%
Không. Bạn lấy ý tưởng này từ đâu? Tất cả các thực hành Agile chấp nhận rằng các yêu cầu thay đổi. Bạn cần phải biết những gì bạn đang làm trước khi bạn làm điều đó, nhưng điều đó không giống như yêu cầu 100%. TDD là một thông lệ phổ biến trong Scrum, trong đó các yêu cầu (Câu chuyện của người dùng), theo định nghĩa, không hoàn thành 100%.

Trước hết, tôi tin rằng vấn đề của bạn liên quan đến kiểm thử đơn vị nói chung hơn TDD, vì tôi không thấy gì thực sự cụ thể về TDD (chu kỳ kiểm tra đầu tiên + đỏ-xanh-tái cấu trúc) trong những gì bạn nói.

Thật khó và không thực tế để duy trì dữ liệu giả lớn.

Bạn có ý nghĩa gì bởi dữ liệu giả? Một giả được cho là chính xác chỉ chứa hầu như bất kỳ dữ liệu nào, tức là không có trường nào ngoài một hoặc hai cần thiết trong thử nghiệm và không có phụ thuộc nào ngoài hệ thống được thử nghiệm. Thiết lập một giá trị giả hoặc giá trị trả về có thể được thực hiện trong một dòng, vì vậy không có gì khủng khiếp.

Nó thậm chí còn khó hơn khi cấu trúc cơ sở dữ liệu trải qua những thay đổi.

Nếu bạn có nghĩa là cơ sở dữ liệu trải qua các thay đổi mà không có sửa đổi phù hợp đã được thực hiện cho mô hình đối tượng, các bài kiểm tra đơn vị chính xác ở đây để cảnh báo bạn về điều đó. Mặt khác, các thay đổi đối với mô hình phải được phản ánh rõ ràng trong các thử nghiệm đơn vị, nhưng với chỉ dẫn biên dịch, đó là một điều dễ dàng để làm.

Ngay cả với MVVM và khả năng kiểm tra GUI, phải mất rất nhiều mã để tạo lại kịch bản GUI.

Bạn nói đúng, việc kiểm tra đơn vị GUI (Chế độ xem) không hề đơn giản và nhiều người đang làm tốt mà không có nó (bên cạnh đó, kiểm tra GUI không phải là một phần của TDD). Ngược lại, đơn vị kiểm tra Trình điều khiển / Trình dẫn / ViewModel / bất kỳ lớp trung gian nào của bạn đều được khuyến nghị cao, thực sự đó là một trong những lý do chính mà các mẫu như MVC hoặc MVVM là.

Tôi có kinh nghiệm rằng TDD hoạt động tốt nếu bạn giới hạn nó theo logic kinh doanh đơn giản. Tuy nhiên logic kinh doanh phức tạp rất khó kiểm tra vì số lượng kết hợp các thử nghiệm (không gian thử nghiệm) là rất lớn.

Nếu logic kinh doanh của bạn phức tạp, việc kiểm tra đơn vị của bạn khó thiết kế là điều bình thường. Tùy thuộc vào bạn để biến chúng thành nguyên tử nhất có thể, mỗi thử nghiệm chỉ có một trách nhiệm của đối tượng được thử nghiệm. Các bài kiểm tra đơn vị là tất cả những gì cần thiết hơn trong một môi trường phức tạp vì chúng cung cấp một mạng lưới bảo mật đảm bảo rằng bạn không vi phạm các quy tắc hoặc yêu cầu kinh doanh khi bạn thay đổi mã.

TDD yêu cầu các yêu cầu là chính xác 100%.

Tuyệt đối không. Phần mềm thành công yêu cầu các yêu cầu phải chính xác 100%;) Các bài kiểm tra đơn vị chỉ phản ánh tầm nhìn của bạn về các yêu cầu hiện tại là gì; nếu tầm nhìn bị khiếm khuyết, mã và phần mềm của bạn cũng vậy, kiểm tra đơn vị hay không ... Và đó là nơi kiểm thử đơn vị tỏa sáng: với tiêu đề kiểm tra đủ rõ ràng, các quyết định thiết kế và giải thích yêu cầu của bạn trở nên minh bạch, giúp dễ dàng chỉ ra hơn ngón tay của bạn về những gì cần thay đổi vào lần tới khi khách hàng của bạn nói, "quy tắc kinh doanh này không hoàn toàn như tôi muốn".

Tôi phải cười khi nghe ai đó phàn nàn rằng lý do họ không thể sử dụng TDD để kiểm tra ứng dụng của họ là vì ứng dụng của họ quá phức tạp. Sự thay thế là gì? Có con khỉ thử đập vào mẫu đất của bàn phím? Hãy để người dùng là người thử nghiệm? Còn gì nữa không Tất nhiên là khó và phức tạp. Bạn có nghĩ rằng Intel không kiểm tra chip của họ cho đến khi họ xuất xưởng không? Làm thế nào "đầu trong cát" đó là?

Tôi đã tìm thấy TDD (và kiểm tra đơn vị nói chung) hầu như không thể vì một lý do liên quan: Các thuật toán phức tạp, mới lạ và / hoặc mờ. Vấn đề tôi gặp phải nhiều nhất trong các nguyên mẫu nghiên cứu tôi viết là tôi không biết câu trả lời đúng là gì ngoài việc chạy mã của tôi. Nó quá phức tạp để tìm ra một cách hợp lý bằng tay cho bất cứ điều gì ngoại trừ những trường hợp tầm thường lố bịch. Điều này đặc biệt đúng nếu thuật toán liên quan đến heuristic, xấp xỉ hoặc không xác định. Tôi vẫn cố gắng kiểm tra chức năng cấp thấp hơn mà mã này phụ thuộc và sử dụng các xác nhận rất nhiều khi kiểm tra độ tỉnh táo. Phương pháp thử nghiệm cuối cùng của tôi là viết hai triển khai khác nhau, lý tưởng bằng hai ngôn ngữ khác nhau bằng hai bộ thư viện khác nhau và so sánh kết quả.

> Does TDD really work for complex projects?

Từ kinh nghiệm của tôi: Có cho Unittests (kiểm tra các mô-đun / tính năng tách biệt) bởi vì những điều này hầu như không có vấn đề bạn đề cập: (Gui, Mvvm, Business-Modell). Tôi chưa bao giờ có nhiều hơn 3 giả / cuống để hoàn thành một lần không đáng tin cậy nhất (nhưng có lẽ tên miền của bạn yêu cầu nhiều hơn).

Tuy nhiên tôi không chắc chắn nếu TDD có thể giải quyết các vấn đề bạn đã đề cập trong quá trình tích hợp hoặc thử nghiệm đầu cuối với các thử nghiệm theo kiểu BDD.

Nhưng ít nhất một số vấn đề có thể được giảm bớt .

> However complex business logic is hard to test since the number 
> of combinations of tests (test space) is very large.

Điều này đúng nếu bạn muốn thực hiện bảo hiểm đầy đủ về mức độ kiểm tra tích hợp hoặc kiểm tra đầu cuối. Nó có thể dễ dàng hơn để thực hiện bảo hiểm đầy đủ ở mức độ không đáng tin cậy nhất.

Ví dụ: Kiểm tra quyền người dùng phức tạp

Kiểm tra Chức năng IsAllowedToEditCusterData()ở cấp độ kiểm thử tích hợp sẽ yêu cầu hỏi các đối tượng khác nhau để biết thông tin về người dùng, tên miền, khách hàng, môi trường .....

Mocking các bộ phận này là khá khác nhau. Điều này đặc biệt đúng nếu IsAllowedToEditCusterData()phải biết những đối tượng khác nhau.

Ở mức không đáng tin cậy, bạn sẽ có Hàm IsAllowedToEditCusterData()lấy ví dụ 20 tham số có chứa mọi thứ mà hàm cần biết. Vì IsAllowedToEditCusterData()không cần biết trường nào a user, a domain, a customer, .... có dễ kiểm tra không.

Khi tôi phải thực hiện, IsAllowedToEditCusterData()tôi đã có hai lần quá tải:

Một tình trạng quá tải không có gì khác hơn là nhận 20 tham số đó và sau đó gọi quá tải với 20 tham số đưa ra quyết định.

(tôi IsAllowedToEditCusterData()chỉ có 5 tham số và tôi cần 32 kết hợp khác nhau để kiểm tra hoàn toàn)

Thí dụ

// method used by businesslogic
// difficuilt to test because you have to construct
// many dependant objects for the test
public boolean IsAllowedToEditCusterData() {
    Employee employee = getCurrentEmployee();
    Department employeeDepartment = employee.getDepartment();
    Customer customer = getCustomer();
    Shop shop = customer.getShop();

    // many more objects where the permittions depend on

    return IsAllowedToEditCusterData(
            employee.getAge(),
            employeeDepartment.getName(),
            shop.getName(),
            ...
        );
}

// method used by junittests
// much more easy to test because only primitives
// and no internal state is needed
public static boolean IsAllowedToEditCusterData(
        int employeeAge,
        String employeeDepartmentName,
        String shopName,
        ... ) 
{
    boolean isAllowed; 
    // logic goes here

    return isAllowed;
}

Câu trả lời buồn là không có gì thực sự hiệu quả cho các dự án phức tạp lớn!

TDD tốt như mọi thứ khác và tốt hơn hầu hết, nhưng một mình TDD sẽ không đảm bảo thành công trong một dự án lớn. Tuy nhiên nó sẽ tăng cơ hội thành công của bạn. Đặc biệt là khi được sử dụng kết hợp với các ngành quản lý dự án khác (xác minh yêu cầu, trường hợp sử dụng, ma trận khả năng chuyển đổi yêu cầu, mã hướng dẫn et.c, v.v.).

Hãy nhớ rằng các bài kiểm tra đơn vị được thực thi thông số kỹ thuật . Điều này đặc biệt có giá trị trong các dự án phức tạp. Nếu cơ sở mã cũ của bạn không có bất kỳ thử nghiệm nào để sao lưu nó, sẽ không ai dám thay đổi bất cứ điều gì vì họ sẽ sợ phá vỡ bất cứ điều gì.

"Wtf. Tại sao chi nhánh mã này thậm chí còn ở đó? Không biết, có lẽ ai đó cần nó, tốt hơn là để nó ở đó hơn là làm phiền bất cứ ai ..." Theo thời gian, các dự án phức tạp trở thành một bãi rác.

Với các bài kiểm tra, bất cứ ai cũng có thể tự tin nói rằng "Tôi đã thực hiện những thay đổi mạnh mẽ, nhưng tất cả các bài kiểm tra vẫn đang trôi qua." Theo định nghĩa, anh ta đã không phá vỡ bất cứ điều gì. Điều này dẫn đến các dự án nhanh hơn có thể phát triển. Có lẽ một trong những lý do chúng tôi vẫn cần mọi người duy trì COBOL là vì thử nghiệm không phổ biến kể từ đó: P

Tôi đã thấy một dự án phức tạp lớn hoàn toàn thất bại khi TDD được sử dụng riêng, tức là không có ít nhất là thiết lập trình gỡ lỗi / IDE. Dữ liệu giả và / hoặc kiểm tra tỏ ra không đủ. Dữ liệu thực của máy khách Beta rất nhạy cảm và không thể sao chép hoặc ghi nhật ký. Vì vậy, nhóm nhà phát triển không bao giờ có thể sửa các lỗi nghiêm trọng biểu hiện khi chỉ vào dữ liệu thực và toàn bộ dự án đã bị hủy bỏ, mọi người đều bị sa thải, toàn bộ bit.

Cách để khắc phục vấn đề này sẽ là kích hoạt nó trong trình gỡ lỗi tại trang web của khách hàng, sống với dữ liệu thực, bước qua mã, với các điểm ngắt, xem biến, xem bộ nhớ, v.v. Tuy nhiên, nhóm này, người nghĩ rằng mã của họ phù hợp để tô điểm cho những tòa tháp ngà đẹp nhất, trong khoảng thời gian gần một năm chưa bao giờ một lần kích hoạt ứng dụng của họ. Điều đó đã thổi vào tâm trí của tôi.

Vì vậy, giống như mọi thứ, sự cân bằng là chìa khóa. TDD có thể tốt nhưng đừng chỉ dựa vào nó.

Tôi nghĩ vậy, thấy Test Driven Development thực sự hoạt động

Năm 2008, Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat và Laurie Williams đã viết một bài báo có tên là Real Real cải thiện chất lượng thông qua phát triển dựa trên thử nghiệm: kết quả và kinh nghiệm của bốn đội công nghiệp (liên kết PDF). Trừu tượng:

Phát triển dựa trên thử nghiệm (TDD) là một thực tiễn phát triển phần mềm đã được sử dụng một cách rời rạc trong nhiều thập kỷ. Với cách làm này, một kỹ sư phần mềm quay vòng từng phút giữa việc viết các bài kiểm tra đơn vị thất bại và viết mã thực hiện để vượt qua các bài kiểm tra đó. Phát triển dựa trên thử nghiệm gần đây đã xuất hiện trở lại như là một thực tiễn quan trọng cho phép thực hành các phương pháp phát triển phần mềm linh hoạt. Tuy nhiên, rất ít bằng chứng thực nghiệm hỗ trợ hoặc bác bỏ tiện ích của thực tiễn này trong bối cảnh công nghiệp. Nghiên cứu trường hợp được thực hiện với ba nhóm phát triển tại Microsoft và một tại IBM đã áp dụng TDD. Kết quả của các nghiên cứu trường hợp chỉ ra rằng mật độ khiếm khuyết trước khi phát hành của bốn sản phẩm giảm từ 40% đến 90% so với các dự án tương tự không sử dụng thực hành TDD. Chủ quan,

Năm 2012, thực tiễn phát triển Ruby on Rails giả định TDD. Cá nhân tôi dựa vào các công cụ như rspec để viết bài kiểm tra và giả, Factory_girl để tạo đối tượng, capybara để tự động hóa trình duyệt, Simplecov để bảo hiểm mã và bảo vệ để tự động hóa các bài kiểm tra này.

Kết quả của việc sử dụng phương pháp này và các công cụ này, tôi có xu hướng đồng ý chủ quan với Nagappan et al ...

Nếu sự kết hợp của ngân sách, các yêu cầu và kỹ năng nhóm nằm trong góc phần tư của dự án - không gian được đặt tên 'từ bỏ hy vọng tất cả các bạn vào đây', thì theo định nghĩa, rất có thể dự án sẽ thất bại.

Có lẽ các yêu cầu rất phức tạp và không ổn định, cơ sở hạ tầng không ổn định, nhóm thiếu niên và có doanh thu cao, hoặc kiến ​​trúc sư là một thằng ngốc.

Trong một dự án TDD, triệu chứng của sự thất bại sắp xảy ra này là các bài kiểm tra không thể được viết theo lịch trình; bạn cố gắng, chỉ để khám phá 'rằng sẽ mất này dài, và chúng tôi chỉ có mà '.

Các phương pháp khác sẽ cho thấy các triệu chứng khác nhau khi chúng thất bại; giao hàng phổ biến nhất của một hệ thống không hoạt động. Chính trị và hợp đồng sẽ xác định liệu đó là thích hợp hơn.

TDDnghe có vẻ đau đớn nhưng về lâu dài nó sẽ là người bạn tốt nhất của bạn, hãy tin tôi TDDsẽ thực sự làm cho ứng dụng có thể duy trì và bảo mật trong thời gian dài.