Trải nghiệm tiêu cực TDD [đã đóng]

Một mặt tiêu cực của kinh nghiệm TDD của bạn là gì? Bạn có thấy các bước bé (cách khắc phục đơn giản nhất để làm cho thử nghiệm màu xanh lá cây) gây phiền nhiễu và vô dụng? Bạn có tìm thấy các thử nghiệm không có giá trị (khi thử nghiệm có ý nghĩa ban đầu nhưng trong quá trình thực hiện cuối cùng sẽ kiểm tra logic giống như thử nghiệm khác) bảo trì quan trọng không? Vân vân.

Các câu hỏi trên là về những điều mà tôi không thoải mái trong quá trình trải nghiệm TDD của mình. Vì vậy, tôi quan tâm liệu các nhà phát triển khác có cảm xúc tương tự và họ nghĩ gì về họ.

Sẽ rất biết ơn về các liên kết đến các bài viết mô tả các mặt tiêu cực của TDD (Google được lấp đầy bởi các bài viết tích cực và thường xuyên cuồng tín).

Giống như mọi thứ xuất hiện dưới biểu ngữ "Agile", TDD là một thứ nghe có vẻ hay trên lý thuyết, nhưng trong thực tế không rõ ràng nó tốt như thế nào (và cũng giống như hầu hết những thứ "Agile", bạn sẽ nói rằng nếu bạn không thích nó, bạn đang làm sai).

Định nghĩa về TDD không được khắc trong đá: những người như Kent Beck yêu cầu một bài kiểm tra không biên dịch phải được viết trước một dòng mã và mỗi dòng mã phải được viết để vượt qua bài kiểm tra thất bại. Thiết kế phía trước là tối thiểu và mọi thứ được thúc đẩybằng các bài kiểm tra. Nó không hoạt động. Tôi đã thấy một ứng dụng doanh nghiệp lớn được phát triển bằng phương pháp đó và tôi hy vọng rằng đó là mã tồi tệ hơn tôi thấy trong sự nghiệp của mình (nó sẽ không còn xa nữa, và điều đó mặc dù có một số nhà phát triển tài năng làm việc trên nó). Từ những gì tôi đã thấy, kết quả là một số lượng lớn các bài kiểm tra được suy nghĩ kém, chủ yếu xác nhận các lệnh gọi hàm xảy ra, các ngoại lệ được đưa ra khi các biến là null và khung mô phỏng được tập luyện kỹ lưỡng (whoop-de-whoop); mã sản xuất của bạn được kết hợp chặt chẽ với các thử nghiệm này và giấc mơ tái cấu trúc liên tục và dễ dàng không xuất hiện - thực tế mọi người thậm chí còn ít có khả năng sửa mã xấu vì tất cả các thử nghiệm sẽ bị hỏng.

Ngược lại, tôi đã nghe mọi người lập luận rằng TDD có nghĩa là thiết kế các bài kiểm tra ở mức độ cao như là một phần của giai đoạn lập kế hoạch - bên cạnh thiết kế kiến ​​trúc. Các thử nghiệm này có thể thay đổi trong quá trình phát triển khi có thêm thông tin, nhưng chúng đã được xem xét cẩn thận và đưa ra một hướng dẫn tốt về những gì mã thực sự nên làm. Đối với tôi điều đó có ý nghĩa hoàn hảo.

Cuộc phỏng vấn Rich Hickey này ( tác giả Clojure ) có chứa những điều sau đây. Tôi cảm thấy đồng cảm 100%:

Cuộc sống rất ngắn ngủi và chỉ có một số giờ hữu hạn trong một ngày. Vì vậy, chúng ta phải lựa chọn về cách chúng ta dành thời gian. Nếu chúng ta dành nó để viết bài kiểm tra, đó là thời gian chúng ta không dành để làm việc khác. Mỗi người trong chúng ta cần đánh giá cách sử dụng thời gian tốt nhất để tối đa hóa kết quả của mình, cả về số lượng và chất lượng. Nếu mọi người nghĩ rằng dành năm mươi phần trăm thời gian của họ để viết bài kiểm tra thì tối đa hóa kết quả của họ, thì họ ổn cho họ. Tôi chắc chắn điều đó không đúng với tôi. Tôi muốn dành thời gian đó để suy nghĩ về vấn đề của mình. Tôi chắc chắn rằng, đối với tôi, điều này tạo ra các giải pháp tốt hơn, với ít khuyết điểm hơn bất kỳ việc sử dụng thời gian nào khác của tôi. Một thiết kế xấu với một bộ thử nghiệm hoàn chỉnh vẫn là một thiết kế xấu.

Một tuyên bố tương tự khác từ Donald Knuth trong cuộc phỏng vấn cuốn sách Coders at Work , được sao chép từ đây :

Seibel: Nói về công việc thực tế, giữa lúc làm việc với Nghệ thuật lập trình máy tính, bạn đã biến những gì thành một kỳ nghỉ mười năm để viết hệ thống sắp chữ của bạn TeX. Tôi hiểu bạn đã viết phiên bản đầu tiên của TeX hoàn toàn cách xa máy tính.

Knuth: Khi tôi viết TeX ban đầu vào năm 1977 và '78, tất nhiên tôi không có lập trình biết chữ nhưng tôi đã có lập trình có cấu trúc. Tôi đã viết nó trong một cuốn sổ tay lớn bằng tay, bằng bút chì. Sáu tháng sau, sau khi tôi đã trải qua toàn bộ dự án, tôi bắt đầu gõ vào máy tính. Và đã gỡ lỗi vào tháng 3 năm 1978 trong khi tôi đã bắt đầu viết chương trình vào tháng 10 năm 1977. Mã cho điều đó là trong kho lưu trữ của Stanford, đó là tất cả bằng bút chì và tất nhiên tôi sẽ quay lại và thay đổi một chương trình con khi tôi biết nó nên như thế nào. Đây là một hệ thống thế hệ đầu tiên, vì vậy rất nhiều kiến ​​trúc khác nhau là có thể và phải bị loại bỏ cho đến khi tôi sống với nó một thời gian và biết những gì ở đó. Và đó là một vấn đề gà và trứng mà bạn không thể gõ cho đến khi bạn có phông chữ nhưng sau đó bạn không thể có phông chữ cho đến khi bạn có thể gõ. Nhưng lập trình có cấu trúc đã cho tôi ý tưởng về sự bất biến và biết cách tạo ra các hộp đen mà tôi có thể hiểu được. Vì vậy, tôi đã tự tin rằng mã sẽ hoạt động khi cuối cùng tôi sẽ gỡ lỗi nó. Tôi cảm thấy rằng tôi sẽ tiết kiệm được rất nhiều thời gian nếu tôi chờ đợi sáu tháng trước khi thử nghiệm bất cứ điều gì. Tôi đã có đủ tự tin rằng mã gần đúng.

Seibel: Và tiết kiệm thời gian sẽ là vì bạn sẽ không dành thời gian xây dựng giàn giáo và cuống để kiểm tra mã chưa hoàn chỉnh?

Knuth: Phải.

Trải nghiệm tiêu cực của tôi với TDD là trải nghiệm đầu tiên của tôi. TDD nghe có vẻ tuyệt vời đối với tôi, tôi đã thực hiện QA trong nhiều năm và vẫn còn những điều kinh khủng trong tâm trí tôi. Tôi muốn dẹp mọi lỗi trước khi biến nó thành bản dựng. Thật không may, sử dụng TDD không đảm bảo rằng bạn sẽ viết bài kiểm tra tốt. Trong thực tế, khuynh hướng ban đầu của tôi là viết các bài kiểm tra đơn giản tạo ra mã đơn giản. Mã thực sự đơn giản mà chứa vài trừu tượng. Các bài kiểm tra thực sự đơn giản được đan xen với các lớp bên trong. Và một khi bạn có vài nghìn bài kiểm tra bitty, bạn chắc chắn không cảm thấy mình di chuyển nhanh hơn khi bạn phải thay đổi một trăm trong số chúng để cấu trúc lại mã của bạn để sử dụng khái niệm miền X rất quan trọng.

Đèn bật sáng cho tôi - TDD không phải là một kỹ năng kiểm tra. Đó là một kỹ năng thiết kế. Nó chỉ có thể dẫn bạn đến mã tốt, đơn giản, khả thi với thực tiễn và nhận thức liên tục về hướng thiết kế mà nó dẫn bạn đến. Nếu bạn viết bài kiểm tra vì mục đích bảo hiểm mã bạn sẽ tạo ra các bài kiểm tra dễ vỡ. Nếu bạn đang viết bài kiểm tra để giúp bạn thiết kế trừu tượng thì đó chỉ là cách viết mã từ trên xuống khắt khe hơn. Trước tiên, bạn có thể xem mã từ phối cảnh của người gọi, điều này khuyến khích bạn làm cho cuộc sống của anh ta dễ dàng hơn, thay vì phản ánh nội bộ của một lớp ra rìa bên ngoài.

Tôi nghĩ TDD là hữu ích, nhưng tôi không giáo điều về nó. Nếu những "kiểm tra không có giá trị" đó đang gây khó khăn cho việc bảo trì - Hãy xóa chúng! Tôi coi các xét nghiệm giống như phần còn lại của mã. Nếu nó có thể được tái cấu trúc đi và làm cho mọi thứ đơn giản hơn, thì hãy làm điều đó!

Tôi đã không nhìn thấy nó một cách cá nhân, nhưng tôi đã nghe nói rằng một số nơi theo dõi phạm vi bảo hiểm và số lượng kiểm tra. Vì vậy, nếu thu thập số liệu là tác dụng phụ của TDD, thì tôi cũng có thể thấy đó là một tiêu cực. Tôi sẽ nhiệt tình xóa 1000 dòng mã, và nếu điều đó làm lỗi 20 lần kiểm tra và giảm tỷ lệ bao phủ mã của tôi%, thì tốt.

Tôi sẽ đi ra ngoài ở đây và tuyên bố với sự trung thực tàn bạo rằng đó thực sự là một sự lãng phí thời gian theo nghi thức. (Trong phần lớn các tình huống.)

Tôi đã mua một cuốn sách về Kiểm thử đơn vị cũng thảo luận về TDD và trong khi tôi đồng ý với các lợi ích của UT, sau khoảng một trăm giờ dùng thử TDD, tôi đã từ bỏ nó vì vô số lý do. Tôi thuộc loại bài đăng chéo ở đây, nhưng TDD:

1. Tài liệu không tốt hơn tài liệu thực.
2. Không bắt lỗi hoặc hồi quy .
3. Không thực sự làm cho thiết kế của tôi tốt hơn so với cuối cùng nếu tôi áp dụng một số khái niệm lập trình chức năng và khả năng kết hợp .
4. Là thời gian có thể được dành tốt hơn để làm đánh giá mã hoặc đánh bóng tài liệu và thông số kỹ thuật.
5. Cung cấp cho các nhà quản lý một cảm giác an toàn sai lầm khi họ nhìn thấy một danh sách hàng trăm biểu tượng màu xanh lá cây.
6. Cải thiện năng suất trong việc thực hiện các thuật toán với ánh xạ đầu vào-đầu ra hạn chế.
7. Có vụng về ở chỗ bạn có thể biết những gì bạn đang làm do TDD, nhưng bạn không hiểu được lý do tại sao nó hoạt động tốt như vậy, tại sao các thiết kế của bạn lại xuất hiện theo cách họ làm.

Một mối quan tâm khác là mức độ hoàn hảo được tranh luận mà người ta phải làm TDD để thực hiện thành công. Một số người nhấn mạnh rằng nếu TDD không được thực hiện liên tục bởi mọi người trong nhóm từ khi bắt đầu dự án, bạn sẽ chỉ phải chịu đựng. Những người khác nhấn mạnh rằng không ai từng làm TDD bởi cuốn sách. Nếu cả hai điều này đều đúng, thì nó sẽ theo sau các học viên TDD đang đau khổ, cho dù họ có nhận ra hay không.

Tất nhiên, nếu người ta lập luận rằng bằng cách thực hiện mọi thứ theo cách tương tự TDD, bạn sẽ tìm đến các thiết kế có thể hoạt động dễ dàng với TDD, có nhiều cách nhanh hơn để đạt được điều đó - cụ thể là, bằng cách thực sự nghiên cứu các khái niệm về khả năng kết hợp. Có rất nhiều nguồn lực ngoài kia, rất nhiều lý thuyết toán học khắt khe (phần lớn là trong lập trình chức năng mà còn trong các lĩnh vực khác). Tại sao không dành tất cả thời gian học TDD của bạn ?

Về mặt văn hóa, TDD cho thấy các triệu chứng là một thực hành nghi lễ. Nó cưỡi trên cảm giác tội lỗi; nó khuyến khích thủ tục hơn sự hiểu biết; nó có vô số học thuyết và khẩu hiệu ("giả mạo cho đến khi bạn thực hiện nó" thực sự khá đáng báo động nếu bạn nhìn vào nó một cách khách quan). Định nghĩa của Wikipedia về từ "nghi lễ" trên thực tế khá phù hợp:

Trong tâm lý học, thuật ngữ nghi thức đôi khi được sử dụng theo nghĩa kỹ thuật cho một hành vi lặp đi lặp lại được sử dụng một cách có hệ thống bởi một người để vô hiệu hóa hoặc ngăn chặn sự lo lắng; đó là một triệu chứng của chứng rối loạn cưỡng chế ám ảnh.

Ngoài ra, một mối quan tâm khác với TDD tôi nhận thấy là:

TDD gây ra sự thay đổi vô tình trong trọng tâm của nhóm phát triển từ Mã chất lượng sang Testcase và Bảo hiểm mã! Cá nhân tôi không thích TDD vì nó khiến tôi kém sáng tạo và khiến việc phát triển phần mềm trở thành một quy trình cơ học buồn tẻ ! Các testcase đơn vị rất hữu ích khi được sử dụng một cách thận trọng nhưng trở thành gánh nặng khi xử lý mục tiêu phát triển phần mềm.

Tôi biết một anh chàng làm quản lý và kỹ thuật đần độn một khi bị ám ảnh bởi TDD. Đó là một điều kỳ diệu đối với anh ta mà anh ta tin rằng sẽ mang lại giải pháp kỳ diệu cho tất cả các vấn đề trong phần mềm có kiến ​​trúc kém của anh ta với mã ít bảo trì nhất. Không nói những gì đã xảy ra với dự án đó - nó thất bại thảm hại trong tay anh ta, trong khi tất cả các cặp thử nghiệm của anh ta đều có màu xanh. Tôi đoán TDD đã giúp anh ta có được một số loại thông tin thống kê như "99/100 trường hợp của tôi là màu xanh lá cây" vv và đó là lý do cho nỗi ám ảnh của anh ta vì anh ta sẽ không bao giờ có thể đánh giá chất lượng hoặc đề xuất cải tiến trong thiết kế.

Trải nghiệm tiêu cực chính của tôi là cố gắng sử dụng TDD để chỉnh sửa mã của một lập trình viên khác, những người không có bài kiểm tra, hoặc các bài kiểm tra tích hợp rất cơ bản. Khi tôi đi để thêm một tính năng, hoặc khắc phục sự cố với mã đã nói; Tôi muốn viết một bài kiểm tra đầu tiên (cách TDD). Thật không may, mã được liên kết chặt chẽ và tôi không thể kiểm tra bất cứ điều gì mà không cần nhiều cấu trúc lại.

Tái cấu trúc dù sao cũng là một bài tập tuyệt vời, nhưng bắt buộc phải đưa mã vào trạng thái có thể kiểm tra được. Và sau bước này, tôi không có kiểm tra và số dư để xem liệu những thay đổi của tôi có phá vỡ điều gì không; thiếu chạy ứng dụng và kiểm tra mọi trường hợp sử dụng.

Mặt khác, việc thêm các tính năng / sửa lỗi cho dự án TDD trở nên rất đơn giản. Về bản chất, mã được viết bằng TDD thường khá tách rời với các phần nhỏ để làm việc.

Trong mọi trường hợp, TDD là một hướng dẫn. Theo nó đến điểm mà bạn thấy bạn có được hiệu quả tối đa. Bảo hiểm kiểm tra Decent và mã tách riêng, mã được viết tốt.

Tôi đã tạo ra trải nghiệm mà đôi khi tôi dựa vào các thử nghiệm của mình quá nhiều khi nói đến thiết kế của hệ thống. Về cơ bản, tôi quá thấp trong các chi tiết triển khai quá thô thiển để lùi bước để nhìn vào bức tranh lớn hơn. Điều này thường dẫn đến một thiết kế phức tạp không cần thiết. Tôi biết, tôi có nghĩa vụ phải cấu trúc lại mã nhưng đôi khi tôi có cảm tưởng rằng tôi có thể tiết kiệm rất nhiều thời gian bằng cách lùi bước thường xuyên hơn.

Điều đó đang được nói, nếu bạn có một khung như đường ray nơi các quyết định kiến ​​trúc của bạn rất hạn chế thì những vấn đề này về cơ bản là không tồn tại.

Một vấn đề khác là khi bạn tin tưởng vào các bài kiểm tra của bạn một cách mù quáng. Sự thật là - giống như bất kỳ mã nào khác - các bài kiểm tra của bạn cũng có thể có lỗi. Vì vậy, rất quan trọng đối với các bài kiểm tra của bạn như bạn đang hướng tới việc thực hiện.

Là một fan hâm mộ lớn của TDD, đôi khi tôi thấy những nhược điểm này

• Cám dỗ viết quá nhiều bài kiểm tra vì mục đích bảo hiểm mã gần như 100%. Theo tôi không cần thiết phải viết bài kiểm tra
  • cho getters / setters tài sản đơn giản
  • cho mọi trường hợp khi một ngoại lệ được ném
  • kiểm tra các chức năng tương tự thông qua các lớp khác nhau. (Ví dụ: nếu bạn không kiểm tra xác thực đầu vào cho mọi tham số thì không nhất thiết phải lặp lại tất cả các thử nghiệm này thông qua thử nghiệm tích hợp).

• Chi phí bảo trì mã kiểm tra cho các thử nghiệm tương tự, chỉ khác nhau một chút (được tạo thông qua sao chép mã (còn gọi là sao chép-dán-kế thừa)). Nếu bạn đã có nó, thật dễ dàng để tạo một cái tương tự. Nhưng nếu bạn không cấu trúc lại mã kiểm tra, bằng cách loại bỏ sao chép mã vào các phương thức của trình trợ giúp, bạn có thể cần một chút thời gian để sửa các kiểm tra nếu chi tiết triển khai của mã doanh nghiệp thay đổi.

• Nếu bạn đang chịu áp lực thời gian, bạn có thể muốn loại bỏ các bài kiểm tra bị hỏng (hoặc nhận xét chúng) thay vì sửa chúng. Bằng cách này, bạn mất khoản đầu tư vào các bài kiểm tra

Tôi vẫn chưa bắt gặp nhiều hơn một kịch bản với tư cách là nhà phát triển trò chơi nơi TDD đáng giá. Và ví dụ, đó là một đoạn mã hoàn toàn là toán học và cần một cách tiếp cận vững chắc để kiểm tra một số lượng lớn các trường hợp cạnh đồng thời - một nhu cầu hiếm gặp.

Có thể một cái gì đó, một ngày nào đó sẽ thay đổi suy nghĩ của tôi, nhưng trong số các thực tiễn XP, ý tưởng tái cấu trúc không thương tiếc và mã phát triển hình thức của chính nó là quan trọng hơn nhiều và dẫn đến năng suất cao nhất đối với tôi, cf một trích dẫn từ một bài báo của James Newkirk :

Đơn giản - "Điều đơn giản nhất có thể làm việc là gì?"
Thông điệp rất rõ ràng. Đưa ra các yêu cầu cho ngày hôm nay, thiết kế và viết phần mềm của bạn. Đừng cố gắng dự đoán tương lai, hãy để tương lai mở ra. Nó thường sẽ làm điều này theo những cách rất khó lường, khiến cho dự đoán trở thành một chi phí thường quá đắt để có thể mua được. "

Các khái niệm về lòng can đảm và thắt chặt các vòng phản hồi mà ông đề cập cũng là, theo tôi, là chìa khóa cho năng suất.

Kinh nghiệm TDD tiêu cực của tôi, hạn chế vì nó có thể, chỉ đơn giản là biết bắt đầu từ đâu! Ví dụ, tôi sẽ cố gắng làm một cái gì đó TDD và một trong hai không có ý tưởng bắt đầu từ đâu chặn thử nghiệm những điều tầm thường (tôi có thể mới lên một Foođối tượng, tôi có thể vượt qua trong một Quuxđến Baz, và những thứ tương tự. Các xét nghiệm mà không kiểm tra bất cứ điều gì ) hoặc nếu tôi đang cố gắng thực hiện nó trong một dự án hiện có thì tôi thấy rằng tôi sẽ phải viết lại các lớp khác nhau để có thể sử dụng chúng trong TDD. Kết quả cuối cùng là tôi nhanh chóng từ bỏ ý niệm hoàn toàn.

Có lẽ điều đó không giúp ích gì cho việc tôi thường là người duy nhất trong toàn công ty biết thử nghiệm đơn vị (TDD hay nói cách khác) là gì và tại sao đó là một điều tốt.

Người nhiệt thành TDD.

Đối với tôi, họ chỉ là một trong những hàng dài những kẻ khốn tôn giáo gõ cửa nhà tôi, cố gắng chứng minh rằng cách làm việc của tôi bị phá vỡ không thể sửa chữa và con đường duy nhất để cứu rỗi là Jesus, Kent Back, hoặc Thử nghiệm đơn vị.

IMO, lời nói dối lớn nhất của họ là TDD sẽ dẫn bạn đến sự cứu rỗi một thiết kế thuật toán tốt hơn. Xem người giải Soduku nổi tiếng được viết bằng TDD: đây , đây , đây , đây và đây

Và so sánh nó, bộ giải sudoku Peter Norvig được thực hiện không phải bằng cách sử dụng TDD, mà sử dụng kỹ thuật lỗi thời: http://norvig.com/sudoku.html

Nếu bạn sử dụng TDD từ các bài báo "cuồng tín" này, bạn sẽ có cảm giác an toàn sai lầm rằng phần mềm của bạn không có lỗi.

TDD có một số lợi ích:

• Bạn tập trung vào cách gọi mã của bạn và những gì mong đợi trước tiên (khi bạn viết bài kiểm tra trước) thay vì tập trung vào giải quyết vấn đề và sau đó bạn dán vào một cuộc gọi từ ứng dụng. Các mô-đun làm cho nó dễ dàng hơn để giả và bọc.
• Các thử nghiệm đảm bảo rằng chương trình của bạn hoạt động giống nhau trước và sau khi tái cấu trúc. Điều này không có nghĩa là chương trình của bạn không có lỗi, nhưng nó vẫn hoạt động theo cùng một cách.

TDD là về đầu tư dài hạn. Nỗ lực được đền đáp khi bạn đạt đến chế độ bảo trì ứng dụng của mình và nếu ứng dụng không được lên kế hoạch để đạt đến điểm đó, bạn có thể không bao giờ thu hồi được khoản đầu tư.

Tôi xem xét chu kỳ đỏ-xanh TDD với các bước bé tương tự như một danh sách kiểm tra cho một mặt phẳng. Thật khó chịu và tẻ nhạt khi kiểm tra từng thứ trong máy bay trước khi cất cánh, đặc biệt nếu nó đơn giản không đáng kể (các bước bé TDD) nhưng người ta thấy rằng nó làm tăng sự an toàn. Bên cạnh việc xác minh mọi thứ hoạt động, về cơ bản nó đặt lại máy bay . Nói cách khác, một chiếc máy bay được khởi động lại trước mỗi lần cất cánh.

Trải nghiệm tiêu cực của tôi về TDD là điều tôi cảm thấy với rất nhiều thứ mới mẻ và cường điệu. Trong thực tế, tôi thích TDD vì nó đảm bảo tính hợp lệ của mã của tôi và thậm chí còn quan trọng hơn: Tôi có thể nhận ra các thử nghiệm thất bại, sau khi thêm mã mới hoặc bất kỳ loại tái cấu trúc nào.

Điều làm tôi khó chịu về TDD là thực tế là có rất nhiều quy tắc hoặc hướng dẫn về nó. Vì nó vẫn còn khá mới, hầu hết chúng ta đều trải nghiệm để trở thành người mới bắt đầu tại TDD. Vì vậy, những gì hoạt động tốt cho một số người trong chúng ta, có thể không làm việc cho những người khác. Điều tôi muốn nói là, không có cách thực sự "sai hay đúng" để thực hiện TDD: Có cách làm việc cho tôi - và nhóm của tôi nếu tôi có.

Vì vậy, miễn là bạn viết thử nghiệm - trước hoặc sau mã sản xuất không thực sự quan trọng IMHO - Tôi không chắc chắn nếu thử nghiệm thực sự có nghĩa là bạn phải tuân theo tất cả các nguyên tắc được nêu ngay bây giờ, vì chúng chưa được chứng minh là giải pháp lý tưởng cho công việc hàng ngày. Nếu bạn tìm thấy một cách tốt hơn trong việc viết bài kiểm tra, bạn nên đăng nó trong một blog, thảo luận về nó ở đây hoặc viết một bài báo về nó. Vì vậy, trong mười năm hoặc lâu hơn, chúng tôi có thể đã chia sẻ đủ kinh nghiệm để có thể biết quy tắc nào của TDD có thể được coi là tốt hay không trong một tình huống nhất định.

Tôi đã, trong hơn một lần, viết mã mà tôi đã loại bỏ vào ngày hôm sau vì nó vụng về. Tôi khởi động lại với TDD và giải pháp tốt hơn. Vì vậy, tôi đã không có quá nhiều trong dòng trải nghiệm TDD tiêu cực. Tuy nhiên, điều đó đã được nói, tôi đã dành thời gian suy nghĩ về một vấn đề và đưa ra một giải pháp tốt hơn ngoài không gian TDD.

Tôi đã tìm thấy TDD hoạt động kém khi nói đến các hệ thống mới nổi. Tôi là nhà phát triển trò chơi video và gần đây đã sử dụng TDD để tạo một hệ thống sử dụng nhiều hành vi đơn giản để tạo chuyển động trông giống như thật cho một thực thể.

Chẳng hạn, có những hành vi chịu trách nhiệm đưa bạn ra khỏi những khu vực nguy hiểm thuộc các loại khác nhau và những hành vi chịu trách nhiệm đưa bạn đến những khu vực thú vị thuộc các loại khác nhau. Hợp nhất đầu ra của mỗi hành vi tạo ra một chuyển động cuối cùng.

Sự can đảm của hệ thống được triển khai dễ dàng và TDD rất hữu ích ở đây để chỉ định mỗi hệ thống con phải chịu trách nhiệm gì.

Tuy nhiên, tôi gặp vấn đề khi chỉ định cách các hành vi tương tác và quan trọng hơn là cách chúng tương tác theo thời gian. Thường thì không có câu trả lời đúng và mặc dù các thử nghiệm ban đầu của tôi đã vượt qua, QA có thể tiếp tục tìm các trường hợp cạnh mà hệ thống không hoạt động. Để tìm ra giải pháp chính xác, tôi đã phải lặp đi lặp lại nhiều hành vi khác nhau và nếu tôi cập nhật các bài kiểm tra mỗi lần để phản ánh các hành vi mới trước khi tôi kiểm tra chúng hoạt động trong trò chơi, tôi có thể đã hết lần này đến lần khác. Vì vậy, tôi đã xóa các bài kiểm tra.

Tôi đáng lẽ phải có những bài kiểm tra mạnh hơn để ghi lại các trường hợp cạnh mà QA đã phát hiện ra, nhưng khi bạn có một hệ thống như thế này nằm trên nhiều hệ thống vật lý và trò chơi, và bạn đang xử lý các hành vi theo thời gian, nó sẽ trở thành một chút ác mộng để xác định chính xác những gì đang xảy ra.

Tôi gần như chắc chắn đã phạm sai lầm trong cách tiếp cận của mình, và như tôi đã nói vì sự can đảm của hệ thống TDD đã hoạt động rất tốt, và thậm chí còn hỗ trợ một vài nhà tái cấu trúc tối ưu hóa.