Nhược điểm của phát triển hướng thử nghiệm? [đóng cửa]

Tôi mất gì khi áp dụng thiết kế hướng thử nghiệm?

Chỉ liệt kê phủ định; không liệt kê các lợi ích được viết dưới dạng tiêu cực.

Một số nhược điểm (và tôi không khẳng định là không có lợi ích - đặc biệt là khi viết nền tảng của một dự án - nó sẽ tiết kiệm rất nhiều thời gian ở cuối):

• Đầu tư thời gian lớn. Đối với trường hợp đơn giản, bạn mất khoảng 20% ​​so với thực hiện thực tế, nhưng đối với các trường hợp phức tạp, bạn mất nhiều hơn thế.
• Độ phức tạp bổ sung. Đối với các trường hợp phức tạp, các trường hợp kiểm thử của bạn khó tính toán hơn, tôi đề nghị trong các trường hợp như vậy hãy thử và sử dụng mã tham chiếu tự động sẽ chạy song song trong phiên bản gỡ lỗi / chạy thử, thay vì kiểm tra đơn vị các trường hợp đơn giản nhất.
• Thiết kế tác động. Đôi khi thiết kế không rõ ràng khi bắt đầu và phát triển khi bạn đi cùng - điều này sẽ buộc bạn phải làm lại bài kiểm tra của mình, điều này sẽ gây ra mất thời gian lớn. Tôi sẽ đề nghị hoãn thử nghiệm đơn vị trong trường hợp này cho đến khi bạn có một số nắm bắt về thiết kế trong tâm trí.
• Tinh chỉnh liên tục. Đối với các cấu trúc dữ liệu và các thử nghiệm đơn vị thuật toán hộp đen sẽ là hoàn hảo, nhưng đối với các thuật toán có xu hướng thay đổi, điều chỉnh hoặc tinh chỉnh, điều này có thể gây ra một khoản đầu tư lớn mà người ta có thể tuyên bố là không hợp lý. Vì vậy, hãy sử dụng nó khi bạn nghĩ rằng nó thực sự phù hợp với hệ thống và không buộc thiết kế phải phù hợp với TDD.

Nếu bạn muốn thực hiện TDD "thực" (đọc: trước tiên hãy kiểm tra các bước tái cấu trúc màu đỏ, xanh lục), thì bạn cũng phải bắt đầu sử dụng giả / cuống, khi bạn muốn kiểm tra các điểm tích hợp.

Khi bạn bắt đầu sử dụng giả, sau một thời gian, bạn sẽ muốn bắt đầu sử dụng Dependency Injection (DI) và thùng chứa Inversion of Control (IoC). Để làm điều đó, bạn cần sử dụng các giao diện cho mọi thứ (có rất nhiều cạm bẫy).

Vào cuối ngày, bạn phải viết nhiều mã hơn, nếu bạn chỉ làm theo "cách cũ đơn giản". Thay vì chỉ là một lớp khách hàng, bạn cũng cần phải viết một giao diện, một lớp giả, một số cấu hình IoC và một vài bài kiểm tra.

Và hãy nhớ rằng mã kiểm tra cũng nên được duy trì và chăm sóc. Các bài kiểm tra nên dễ đọc như mọi thứ khác và cần có thời gian để viết mã tốt.

Nhiều nhà phát triển không hiểu làm thế nào để thực hiện tất cả những "cách đúng đắn" này. Nhưng bởi vì mọi người nói với họ rằng TDD là cách thực sự duy nhất để phát triển phần mềm, họ chỉ cố gắng hết sức có thể.

Nó khó hơn nhiều so với người ta có thể nghĩ. Thông thường các dự án được thực hiện với TDD kết thúc với rất nhiều mã mà không ai thực sự hiểu. Các bài kiểm tra đơn vị thường kiểm tra sai, sai cách. Và không ai đồng ý rằng một bài kiểm tra tốt sẽ trông như thế nào, thậm chí không phải là người được gọi là bậc thầy.

Tất cả những thử nghiệm đó làm cho việc "thay đổi" (ngược lại với tái cấu trúc) trở nên khó khăn hơn rất nhiều đối với hệ thống của bạn và những thay đổi đơn giản trở nên quá khó khăn và tốn thời gian.

Nếu bạn đọc tài liệu TDD, luôn có một số ví dụ rất hay, nhưng thường trong các ứng dụng thực tế, bạn phải có giao diện người dùng và cơ sở dữ liệu. Đây là lúc TDD thực sự khó khăn và hầu hết các nguồn không cung cấp câu trả lời hay. Và nếu họ làm như vậy, nó luôn liên quan đến nhiều khái niệm trừu tượng hơn: các đối tượng giả, lập trình cho một giao diện, các mẫu MVC / MVP, v.v., một lần nữa đòi hỏi nhiều kiến ​​thức và ... bạn phải viết nhiều mã hơn nữa.

Vì vậy, hãy cẩn thận ... nếu bạn không có một đội ngũ nhiệt tình và ít nhất một nhà phát triển có kinh nghiệm, biết viết các bài kiểm tra tốt và cũng biết một vài điều về kiến ​​trúc tốt, bạn thực sự phải suy nghĩ kỹ trước khi đi xuống con đường TDD .

Khi bạn đến điểm mà bạn có số lượng thử nghiệm lớn, việc thay đổi hệ thống có thể yêu cầu viết lại một số hoặc tất cả các thử nghiệm của bạn, tùy thuộc vào thử nghiệm nào bị vô hiệu bởi các thay đổi. Điều này có thể biến một sửa đổi tương đối nhanh chóng thành một sửa đổi rất tốn thời gian.

Ngoài ra, bạn có thể bắt đầu đưa ra quyết định thiết kế dựa trên TDD nhiều hơn so với các dự đoán thiết kế thực sự tốt. Trong khi bạn có thể đã có một giải pháp rất đơn giản, dễ dàng mà không thể kiểm tra theo cách TDD yêu cầu, thì bây giờ bạn có một hệ thống phức tạp hơn nhiều mà thực sự dễ mắc lỗi hơn.

Tôi nghĩ vấn đề lớn nhất đối với tôi là mất rất nhiều thời gian để "vào đó". Tôi vẫn còn rất nhiều khi bắt đầu hành trình với TDD (Xem blog của tôi để cập nhật những cuộc phiêu lưu thử nghiệm của tôi nếu bạn quan tâm) và tôi đã dành hàng giờ để bắt đầu.

Phải mất một thời gian dài để đưa bộ não của bạn vào "chế độ thử nghiệm" và viết "mã có thể kiểm tra" là một kỹ năng.

TBH, tôi không đồng ý với ý kiến ​​của Jason Cohen về việc công khai các phương thức riêng tư, đó không phải là vấn đề. Tôi đã không thực hiện nhiều phương pháp công khai trong cách làm việc mới của tôi hơn trước đây . Tuy nhiên, nó liên quan đến những thay đổi kiến ​​trúc và cho phép bạn "cắm nóng" các mô-đun mã để làm cho mọi thứ khác dễ kiểm tra hơn. Bạn không nên làm cho phần bên trong mã của bạn dễ truy cập hơn để làm điều này. Nếu không, chúng ta quay lại quảng trường một với mọi thứ được công khai, đóng gói trong đó ở đâu?

Vì vậy, (IMO) một cách ngắn gọn:

• Lượng thời gian cần suy nghĩ (nghĩa là thực sự thử nghiệm ).
• Các kiến ​​thức mới cần có để biết cách viết mã thử nghiệm.
• Hiểu những thay đổi kiến ​​trúc cần thiết để làm cho mã có thể kiểm tra được.
• Tăng kỹ năng "TDD-Coder" của bạn trong khi cố gắng cải thiện tất cả các kỹ năng khác cần thiết cho nghề lập trình vinh quang của chúng tôi :)
• Tổ chức cơ sở mã của bạn để bao gồm mã kiểm tra mà không làm hỏng mã sản xuất của bạn.

  ---

PS: Nếu bạn muốn liên kết đến tích cực, tôi đã hỏi và trả lời một số câu hỏi về nó, hãy xem hồ sơ của tôi .

Trong vài năm tôi đã thực hành Phát triển hướng thử nghiệm, tôi phải nói rằng nhược điểm lớn nhất là:

Bán cho quản lý

TDD được thực hiện tốt nhất theo cặp. Đối với một người, thật khó để chống lại sự thôi thúc chỉ viết bản thực hiện khi bạn BIẾT cách viết một câu lệnh if / other . Nhưng một cặp sẽ giữ bạn trong nhiệm vụ bởi vì bạn giữ anh ta trên nhiệm vụ. Đáng buồn thay, nhiều công ty / người quản lý không nghĩ rằng đây là một cách sử dụng tài nguyên tốt. Tại sao phải trả tiền cho hai người để viết một tính năng, khi tôi có hai tính năng cần được thực hiện cùng một lúc?

Bán nó cho các nhà phát triển khác

Một số người không đủ kiên nhẫn để viết bài kiểm tra đơn vị. Một số rất tự hào về công việc của họ. Hoặc, một số giống như nhìn thấy các phương thức / chức năng phức tạp bị chảy máu ở cuối màn hình. TDD không dành cho tất cả mọi người, nhưng tôi thực sự mong muốn nó. Nó sẽ làm cho việc duy trì công cụ trở nên dễ dàng hơn nhiều đối với những linh hồn nghèo khổ thừa hưởng mã.

Duy trì mã kiểm tra cùng với mã sản xuất của bạn

Lý tưởng nhất là các bài kiểm tra của bạn sẽ chỉ bị hỏng khi bạn đưa ra một quyết định mã xấu. Đó là, bạn nghĩ rằng hệ thống hoạt động theo một cách, và hóa ra nó không hoạt động. Bằng cách phá vỡ một bài kiểm tra, hoặc một bộ (nhỏ) các bài kiểm tra, đây thực sự là một tin tốt. Bạn biết chính xác làm thế nào mã mới của bạn sẽ ảnh hưởng đến hệ thống. Tuy nhiên, nếu các bài kiểm tra của bạn được viết kém, kết hợp chặt chẽ hoặc tệ hơn là được tạo ra ( ho VS Test), thì việc duy trì các bài kiểm tra của bạn có thể nhanh chóng trở thành hợp xướng. Và, sau khi đủ các thử nghiệm bắt đầu gây ra nhiều công việc hơn mà giá trị cảm nhận mà chúng đang tạo ra, thì các thử nghiệm sẽ là điều đầu tiên bị xóa khi lịch trình bị nén (ví dụ: thời gian bị khủng hoảng)

Viết bài kiểm tra để bạn bao quát mọi thứ (bảo hiểm mã 100%)

Lý tưởng hơn, một lần nữa, nếu bạn tuân thủ phương pháp luận, mã của bạn sẽ được kiểm tra 100% theo mặc định. Thông thường, tôi nghĩ, tôi kết thúc với độ bao phủ mã lên tới 90%. Điều này thường xảy ra khi tôi có một số kiến ​​trúc kiểu mẫu và cơ sở được kiểm tra và tôi cố gắng cắt các góc và không kiểm tra các tùy chỉnh mẫu. Ngoài ra, tôi đã phát hiện ra rằng khi tôi gặp một rào cản mới mà tôi chưa từng gặp trước đây, tôi có một đường cong học tập trong việc kiểm tra nó. Tôi sẽ thừa nhận viết một số dòng mã theo cách skool cũ, nhưng tôi thực sự muốn có 100% đó. (Tôi đoán tôi là một người thành đạt ở trường, er skool).

Tuy nhiên, với điều đó tôi đã nói rằng lợi ích của TDD vượt xa những tiêu cực đối với ý tưởng đơn giản rằng nếu bạn có thể đạt được một bộ thử nghiệm tốt bao trùm ứng dụng của mình nhưng không dễ vỡ đến mức một thay đổi sẽ phá vỡ tất cả, bạn sẽ có thể tiếp tục thêm các tính năng mới vào ngày 300 của dự án của bạn như bạn đã làm vào ngày 1. Điều này không xảy ra với tất cả những ai dùng thử TDD nghĩ rằng đó là một viên đạn ma thuật cho tất cả các mã bị lỗi của họ, và vì vậy họ nghĩ rằng nó có thể 't làm việc, thời gian.

Cá nhân tôi đã thấy rằng với TDD, tôi viết mã đơn giản hơn, tôi dành ít thời gian hơn để tranh luận liệu một giải pháp mã cụ thể có hoạt động hay không và tôi không sợ phải thay đổi bất kỳ dòng mã nào không đáp ứng các tiêu chí được đặt ra bởi đội.

TDD là một môn học khó để thành thạo, và tôi đã ở đó được vài năm và tôi vẫn học các kỹ thuật kiểm tra mới mọi lúc. Đó là một khoản đầu tư thời gian khổng lồ lên phía trước, nhưng, về lâu dài, tính bền vững của bạn sẽ lớn hơn nhiều so với việc bạn không có bài kiểm tra đơn vị tự động. Bây giờ, nếu chỉ có ông chủ của tôi có thể tìm ra điều này.

Trong dự án TDD đầu tiên của bạn, có hai mất mát lớn, thời gian và tự do cá nhân

Bạn mất thời gian vì:

• Việc tạo ra một bộ kiểm tra đơn vị và chấp nhận toàn diện, được tái cấu trúc, có thể bảo trì sẽ thêm thời gian chính cho lần lặp đầu tiên của dự án. Đây có thể là thời gian tiết kiệm trong thời gian dài nhưng cũng có thể là thời gian bạn không cần phải rảnh rỗi.
• Bạn cần chọn và trở thành chuyên gia trong một bộ công cụ cốt lõi. Một công cụ kiểm tra đơn vị cần được bổ sung bởi một số loại khung mô phỏng và cả hai cần phải trở thành một phần của hệ thống xây dựng tự động của bạn. Bạn cũng muốn chọn và tạo số liệu thích hợp.

Bạn mất tự do cá nhân vì:

• TDD là một cách viết mã rất kỷ luật, có xu hướng cọ xát thô với những người ở trên cùng và dưới cùng của thang kỹ năng. Luôn viết mã sản xuất theo một cách nhất định và khiến công việc của bạn phải được đánh giá ngang hàng liên tục có thể khiến các nhà phát triển tồi tệ nhất và giỏi nhất của bạn thất vọng và thậm chí dẫn đến mất số lượng nhân viên.
• Hầu hết các phương thức Agile nhúng TDD yêu cầu bạn liên tục nói chuyện với khách hàng về những gì bạn đề xuất để thực hiện (trong câu chuyện / ngày / bất cứ điều gì) và những gì đánh đổi là gì. Một lần nữa, đây không phải là tách trà của mọi người, cả về phía nhà phát triển của hàng rào và khách hàng.

Hi vọng điêu nay co ich

TDD yêu cầu bạn lên kế hoạch về cách các lớp học của bạn sẽ hoạt động trước khi bạn viết mã để vượt qua các bài kiểm tra đó. Đây là cả một điểm cộng và một điểm trừ.

Tôi thấy thật khó để viết các bài kiểm tra trong "chân không" - trước khi bất kỳ mã nào được viết. Theo kinh nghiệm của tôi, tôi có xu hướng vượt qua các bài kiểm tra của mình bất cứ khi nào tôi chắc chắn nghĩ về điều gì đó trong khi viết các lớp học mà tôi đã quên trong khi viết các bài kiểm tra ban đầu của mình. Sau đó, đã đến lúc không chỉ tái cấu trúc các lớp học của tôi, mà C ALNG các bài kiểm tra của tôi. Lặp lại ba hoặc bốn lần này và nó có thể gây bực bội.

Tôi thích viết một bản nháp của các lớp học của tôi trước sau đó viết (và duy trì) một bài kiểm tra đơn vị. Sau khi tôi có một bản nháp, TDD hoạt động tốt với tôi. Ví dụ: nếu một lỗi được báo cáo, tôi sẽ viết một bài kiểm tra để khai thác lỗi đó và sau đó sửa mã để bài kiểm tra vượt qua.

Tạo mẫu có thể rất khó với TDD - khi bạn không chắc chắn mình sẽ đi theo con đường nào để giải quyết, việc viết các bài kiểm tra trước có thể khó khăn (trừ những bài rất rộng). Đây có thể là một nỗi đau.

Thành thật mà nói tôi không nghĩ rằng "phát triển cốt lõi" cho phần lớn các dự án, mặc dù có bất kỳ nhược điểm thực sự nào; nó đã được nói nhiều hơn bình thường, thông thường bởi những người tin rằng mã của họ đủ tốt để họ không cần kiểm tra (không bao giờ) và những người chỉ đơn giản là không thể bận tâm viết chúng.

Vâng, và điều này kéo dài, bạn cần gỡ lỗi các bài kiểm tra của bạn. Ngoài ra, có một chi phí nhất định về thời gian để viết các bài kiểm tra, mặc dù hầu hết mọi người đều đồng ý rằng đó là một khoản đầu tư trực tiếp trả hết thời gian của ứng dụng trong cả thời gian gỡ lỗi và ổn định.

Tuy nhiên, vấn đề lớn nhất mà cá nhân tôi gặp phải với nó là việc đạt được kỷ luật để thực sự viết các bài kiểm tra. Trong một nhóm, đặc biệt là một nhóm được thành lập, thật khó để thuyết phục họ rằng thời gian bỏ ra là đáng giá.

Nếu các bài kiểm tra của bạn không kỹ lưỡng, bạn có thể rơi vào cảm giác sai lầm về "mọi thứ hoạt động" chỉ vì bạn kiểm tra vượt qua. Về mặt lý thuyết nếu các bài kiểm tra của bạn vượt qua, mã đang hoạt động; nhưng nếu chúng ta có thể viết mã hoàn hảo ngay lần đầu tiên, chúng ta sẽ không cần kiểm tra. Đạo đức ở đây là đảm bảo tự kiểm tra sự tỉnh táo trước khi gọi một cái gì đó hoàn chỉnh, đừng chỉ dựa vào các bài kiểm tra.

Trên lưu ý đó, nếu kiểm tra độ tỉnh táo của bạn tìm thấy thứ gì đó không được kiểm tra, hãy đảm bảo quay lại và viết bài kiểm tra cho nó.

Nhược điểm của TDD là nó thường được liên kết chặt chẽ với phương pháp 'Agile', vốn không quan trọng về tài liệu của một hệ thống, thay vào đó là sự hiểu biết tại sao một bài kiểm tra 'nên' trả về một giá trị cụ thể thay vì bất kỳ giá trị nào khác chỉ nằm trong nhà phát triển cái đầu.

Ngay khi nhà phát triển rời khỏi hoặc quên đi lý do thử nghiệm trả về một giá trị cụ thể chứ không phải một giá trị nào khác, bạn đã bị lừa. TDD vẫn ổn NẾU nó được ghi chép đầy đủ và được bao quanh bởi tài liệu có thể đọc được (ví dụ: người quản lý tóc nhọn) có thể được đề cập trong 5 năm khi thế giới thay đổi và ứng dụng của bạn cũng cần phải như vậy.

Khi tôi nói về tài liệu, đây không phải là một lỗi trong mã, đây là văn bản chính thức tồn tại bên ngoài ứng dụng, chẳng hạn như các trường hợp sử dụng và thông tin cơ bản có thể được giới thiệu bởi các nhà quản lý, luật sư và người nghèo phải cập nhật mã của bạn trong năm 2011.

Tôi đã gặp một vài tình huống trong đó TDD khiến tôi phát điên. Để đặt tên cho một số:

• Kiểm tra bảo trì trường hợp:

  Nếu bạn đang ở trong một doanh nghiệp lớn, nhiều khả năng là bạn không phải tự viết các trường hợp thử nghiệm hoặc ít nhất là hầu hết chúng được viết bởi người khác khi bạn vào công ty. Các tính năng của ứng dụng thay đổi theo thời gian và nếu bạn không có hệ thống, chẳng hạn như Trung tâm Chất lượng HP, để theo dõi chúng, bạn sẽ trở nên điên cuồng ngay lập tức.

  Điều này cũng có nghĩa là sẽ mất nhiều thời gian để nắm bắt những gì đang xảy ra với các trường hợp thử nghiệm. Đổi lại, điều này có thể được dịch thành nhiều tiền cần thiết hơn.

• Kiểm tra độ phức tạp tự động hóa:

  Nếu bạn tự động hóa một số hoặc tất cả các trường hợp thử nghiệm thành các tập lệnh kiểm tra có thể chạy bằng máy, bạn sẽ phải đảm bảo các tập lệnh kiểm tra này đồng bộ với các trường hợp kiểm tra thủ công tương ứng của chúng và phù hợp với các thay đổi của ứng dụng.

  Ngoài ra, bạn sẽ dành thời gian để gỡ lỗi các mã giúp bạn bắt lỗi. Theo tôi, hầu hết các lỗi này đến từ sự thất bại của nhóm thử nghiệm trong việc phản ánh các thay đổi của ứng dụng trong tập lệnh thử nghiệm tự động hóa. Những thay đổi trong logic nghiệp vụ, GUI và các nội dung khác có thể khiến tập lệnh của bạn ngừng chạy hoặc chạy không đáng tin cậy. Đôi khi những thay đổi rất tinh tế và khó phát hiện. Khi tất cả các tập lệnh của tôi báo cáo lỗi vì chúng dựa trên tính toán của chúng dựa trên thông tin từ bảng 1 trong khi bảng 1 bây giờ là bảng 2 (vì ai đó đã hoán đổi tên của các đối tượng bảng trong mã ứng dụng).

Vấn đề lớn nhất là những người không biết cách viết bài kiểm tra đơn vị phù hợp. Họ viết các bài kiểm tra phụ thuộc lẫn nhau (và chúng hoạt động rất tốt với Ant, nhưng rồi tất cả đều thất bại khi tôi chạy chúng từ Eclipse, chỉ vì chúng chạy theo thứ tự khác nhau). Họ viết các bài kiểm tra không kiểm tra bất cứ điều gì cụ thể - họ chỉ gỡ lỗi mã, kiểm tra kết quả và thay đổi nó thành kiểm tra, gọi đó là "test1". Họ mở rộng phạm vi của các lớp và phương thức, chỉ vì sẽ dễ dàng hơn để viết các bài kiểm tra đơn vị cho chúng. Mã của các bài kiểm tra đơn vị là khủng khiếp, với tất cả các vấn đề lập trình cổ điển (khớp nối nặng, các phương thức dài 500 dòng, giá trị mã hóa cứng, sao chép mã) và là một địa ngục để duy trì. Vì một số lý do kỳ lạ, mọi người coi các bài kiểm tra đơn vị là một thứ gì đó kém hơn mã "thực" và họ không ' t quan tâm đến chất lượng của họ cả. :-(

Bạn mất rất nhiều thời gian dành cho bài kiểm tra viết. Tất nhiên, điều này có thể được lưu vào cuối dự án bằng cách bắt lỗi nhanh hơn.

Nhược điểm lớn nhất là nếu bạn thực sự muốn làm TDD đúng cách, bạn sẽ phải thất bại rất nhiều trước khi thành công. Dựa vào số lượng công ty phần mềm hoạt động (đô la trên mỗi KLOC), cuối cùng bạn sẽ bị sa thải. Ngay cả khi mã của bạn nhanh hơn, sạch hơn, dễ bảo trì hơn và có ít lỗi hơn.

Nếu bạn đang làm việc trong một công ty trả tiền cho bạn bằng các KLOC (hoặc các yêu cầu được thực hiện - ngay cả khi không được kiểm tra), hãy tránh xa TDD (hoặc đánh giá mã, hoặc lập trình cặp hoặc Tích hợp liên tục, v.v.).

Bạn mất khả năng nói rằng bạn đã "hoàn thành" trước khi kiểm tra tất cả mã của mình.

Bạn mất khả năng viết hàng trăm hoặc hàng ngàn dòng mã trước khi chạy nó.

Bạn mất cơ hội học hỏi thông qua gỡ lỗi.

Bạn mất tính linh hoạt để gửi mã mà bạn không chắc chắn.

Bạn mất tự do để kết hợp chặt chẽ các mô-đun của bạn.

Bạn mất tùy chọn để bỏ qua việc viết tài liệu thiết kế cấp thấp.

Bạn mất đi sự ổn định đi kèm với mã mà mọi người đều sợ thay đổi.

Tôi thứ hai câu trả lời về thời gian phát triển ban đầu. Bạn cũng mất khả năng làm việc dễ dàng mà không có sự an toàn của các bài kiểm tra. Tôi cũng đã được mô tả như là một nutbar TDD, vì vậy bạn có thể mất một vài người bạn;)

Nó được cho là chậm hơn. Về lâu dài, điều đó không đúng về mặt đau buồn, nó sẽ giúp bạn tiết kiệm, nhưng cuối cùng bạn sẽ viết nhiều mã hơn nên có thể cho rằng bạn đang dành thời gian cho "thử nghiệm không mã hóa". Đó là một lập luận thiếu sót, nhưng bạn đã hỏi!

Tập trung vào các yêu cầu khó khăn, không lường trước được là nguyên nhân thường xuyên của lập trình viên. Phát triển dựa trên thử nghiệm buộc bạn phải tập trung vào các yêu cầu đã được biết đến, trần tục và giới hạn sự phát triển của bạn theo những gì đã được tưởng tượng.

Hãy suy nghĩ về điều này, có khả năng bạn sẽ kết thúc việc thiết kế cho các trường hợp thử nghiệm cụ thể, vì vậy bạn sẽ không sáng tạo và bắt đầu nghĩ rằng "thật tuyệt nếu người dùng có thể làm X, Y và Z". Do đó, khi người dùng đó bắt đầu hào hứng với các yêu cầu thú vị tiềm năng X, Y và Z, thiết kế của bạn có thể quá tập trung vào các trường hợp thử nghiệm đã được chỉ định và sẽ rất khó điều chỉnh.

Điều này, tất nhiên, là một con dao hai lưỡi. Nếu bạn dành toàn bộ thời gian để thiết kế cho mọi thứ có thể tưởng tượng, X, Y và Z mà người dùng có thể muốn, chắc chắn bạn sẽ không bao giờ hoàn thành bất cứ điều gì. Nếu bạn hoàn thành một cái gì đó, sẽ không ai có thể biết được những gì bạn đang làm trong mã / thiết kế của mình.

Nó có thể khó và tốn thời gian viết các bài kiểm tra cho dữ liệu "ngẫu nhiên" như nguồn cấp dữ liệu XML và cơ sở dữ liệu (không khó lắm). Gần đây tôi đã dành thời gian làm việc với các nguồn cấp dữ liệu thời tiết. Nó khá khó hiểu khi viết bài kiểm tra cho điều đó, ít nhất là vì tôi không có quá nhiều kinh nghiệm với TDD.

Bạn sẽ mất các lớp lớn với nhiều trách nhiệm. Bạn cũng có thể sẽ mất các phương thức lớn với nhiều trách nhiệm. Bạn có thể mất một số khả năng tái cấu trúc, nhưng bạn cũng sẽ mất một số nhu cầu tái cấu trúc.

Jason Cohen đã nói điều gì đó như: TDD yêu cầu một tổ chức nhất định cho mã của bạn. Điều này có thể sai về mặt kiến ​​trúc; ví dụ, vì các phương thức riêng tư không thể được gọi bên ngoài một lớp, bạn phải làm cho các phương thức không riêng tư để làm cho chúng có thể kiểm tra được.

Tôi nói điều này chỉ ra một sự trừu tượng bị bỏ lỡ - nếu mã riêng thực sự cần phải được kiểm tra, thì nó có lẽ phải ở trong một lớp riêng biệt.

Dave Mann

Bạn phải viết các ứng dụng theo một cách khác: một cách làm cho chúng có thể kiểm tra được. Bạn sẽ ngạc nhiên khi điều này khó khăn như thế nào lúc đầu.

Một số người tìm thấy khái niệm suy nghĩ về những gì họ sẽ viết trước khi họ viết nó quá khó. Các khái niệm như chế giễu cũng có thể khó khăn đối với một số người. TDD trong các ứng dụng cũ có thể rất khó nếu chúng không được thiết kế để thử nghiệm. TDD xung quanh các khung không thân thiện với TDD cũng có thể là một cuộc đấu tranh.

TDD là một kỹ năng để các nhà phát triển cơ sở có thể đấu tranh lúc đầu (chủ yếu vì họ không được dạy để làm việc theo cách này).

Nhìn chung, mặc dù các khuyết điểm đã được giải quyết khi mọi người trở nên lành nghề và cuối cùng bạn đã trừu tượng hóa mã 'có mùi' và có một hệ thống ổn định hơn.

Phải mất một chút thời gian để bắt đầu và một chút thời gian để bắt đầu thực hiện nó trong một dự án nhưng ... Tôi luôn hối hận vì đã không thực hiện phương pháp Test Driven khi tôi tìm thấy những lỗi ngớ ngẩn mà một bài kiểm tra tự động có thể tìm thấy rất nhanh. Ngoài ra, TDD cải thiện chất lượng mã.

• kiểm thử đơn vị là nhiều mã hơn để viết, do đó chi phí phát triển cao hơn
• nó là nhiều mã hơn để duy trì
• yêu cầu học tập bổ sung

Câu trả lời tốt tất cả. Tôi sẽ thêm một vài cách để tránh mặt tối của TDD:

• Tôi đã viết ứng dụng để tự kiểm tra ngẫu nhiên. Vấn đề với việc viết các bài kiểm tra cụ thể là ngay cả khi bạn viết nhiều bài, chúng chỉ bao gồm các trường hợp bạn nghĩ đến. Trình tạo thử nghiệm ngẫu nhiên tìm thấy các vấn đề bạn không nghĩ đến.

• Toàn bộ khái niệm về rất nhiều bài kiểm tra đơn vị ngụ ý rằng bạn có các thành phần có thể vào trạng thái không hợp lệ, như cấu trúc dữ liệu phức tạp. Nếu bạn tránh xa các cấu trúc dữ liệu phức tạp thì sẽ có rất ít thứ để kiểm tra.

• Trong phạm vi ứng dụng của bạn cho phép nó, hãy ngại thiết kế dựa trên thứ tự thích hợp của thông báo, sự kiện và tác dụng phụ. Những người có thể dễ dàng bị rơi hoặc tranh giành vì vậy họ cần rất nhiều thử nghiệm.

TDD yêu cầu một tổ chức nhất định cho mã của bạn. Điều này có thể không hiệu quả hoặc khó đọc. Hoặc thậm chí sai về mặt kiến ​​trúc; ví dụ, vì privatecác phương thức không thể được gọi bên ngoài một lớp, bạn phải làm cho các phương thức không riêng tư để làm cho chúng có thể kiểm tra được, điều này là sai.

Khi mã thay đổi, bạn cũng phải thay đổi các bài kiểm tra. Với tái cấu trúc điều này có thể là rất nhiều công việc thêm.

Tôi xin nói thêm rằng nếu bạn áp dụng các nguyên tắc BDD cho dự án TDD, bạn có thể giảm bớt một số nhược điểm chính được liệt kê ở đây (nhầm lẫn, hiểu lầm, v.v.). Nếu bạn không quen thuộc với BDD, bạn nên đọc phần giới thiệu của Dan North. Ông đã đưa ra khái niệm để trả lời cho một số vấn đề nảy sinh từ việc áp dụng TDD tại nơi làm việc. Giới thiệu của Dan đến BDD có thể được tìm thấy ở đây .

Tôi chỉ đưa ra đề nghị này vì BDD giải quyết một số tiêu cực này và hoạt động như một điểm dừng. Bạn sẽ muốn xem xét điều này khi thu thập phản hồi của bạn.

Bạn phải chắc chắn rằng các bài kiểm tra của bạn luôn được cập nhật, thời điểm bạn bắt đầu bỏ qua đèn đỏ là khoảnh khắc các bài kiểm tra trở nên vô nghĩa.

Bạn cũng phải đảm bảo các bài kiểm tra là toàn diện, hoặc khi một lỗi lớn xuất hiện, kiểu quản lý ngột ngạt mà bạn cuối cùng đã thuyết phục để cho phép bạn dành thời gian viết thêm mã sẽ phàn nàn.

Người dạy nhóm phát triển nhanh nhẹn của tôi không tin vào kế hoạch, bạn chỉ viết nhiều nhất cho yêu cầu nhỏ nhất.

Phương châm của ông là tái cấu trúc, tái cấu trúc, tái cấu trúc. Tôi đã hiểu rằng refactor có nghĩa là 'không lên kế hoạch trước'.

Thời gian phát triển tăng: Mọi phương pháp đều cần thử nghiệm và nếu bạn có một ứng dụng lớn với các phụ thuộc, bạn cần chuẩn bị và dọn dẹp dữ liệu của mình để kiểm tra.