Tại sao TDD hoạt động? [đóng cửa]

Phát triển dựa trên thử nghiệm (TDD) là những ngày lớn. Tôi thường thấy nó được đề xuất như một giải pháp cho một loạt các vấn đề ở đây trong Lập trình viên SE và các địa điểm khác. Tôi tự hỏi tại sao nó hoạt động.

Từ quan điểm kỹ thuật, nó đánh đố tôi vì hai lý do:

1. Phương pháp "viết thử + tái cấu trúc cho đến khi vượt qua" trông cực kỳ phản kỹ thuật. Ví dụ, nếu các kỹ sư dân sự sử dụng phương pháp đó để xây dựng cầu, hoặc thiết kế xe hơi cho ô tô của họ, họ sẽ định hình lại cầu hoặc ô tô của họ với chi phí rất cao, và kết quả sẽ là một mớ hỗn độn không có kiến ​​trúc chu đáo . Hướng dẫn "tái cấu trúc cho đến khi vượt qua" thường được coi là một nhiệm vụ để quên thiết kế kiến ​​trúc và làm bất cứ điều gì cần thiết để tuân thủ thử nghiệm; nói cách khác, bài kiểm tra, thay vì người dùng, đặt ra yêu cầu. Trong tình huống này, làm thế nào chúng ta có thể đảm bảo "bất hợp pháp" tốt trong kết quả, tức là kết quả cuối cùng không chỉ đúng mà còn có thể mở rộng, mạnh mẽ, dễ sử dụng, đáng tin cậy, an toàn, an toàn, v.v.? Đây là những gì kiến ​​trúc thường làm.
2. Kiểm tra không thể đảm bảo rằng một hệ thống hoạt động; nó chỉ có thể cho thấy rằng nó không. Nói cách khác, kiểm tra có thể cho bạn thấy rằng một hệ thống có lỗi nếu nó không thực hiện kiểm tra, nhưng một hệ thống vượt qua tất cả các kiểm tra không an toàn hơn một hệ thống làm hỏng chúng. Kiểm tra bảo hiểm, chất lượng kiểm tra và các yếu tố khác là rất quan trọng ở đây. Cảm giác an toàn sai lầm mà một kết quả "toàn màu xanh" tạo ra cho nhiều người đã được báo cáo trong các ngành công nghiệp dân dụng và hàng không vũ trụ là cực kỳ nguy hiểm, bởi vì nó có thể được coi là "hệ thống vẫn ổn", khi nó thực sự có nghĩa là "hệ thống này rất tốt như chiến lược thử nghiệm của chúng tôi ". Thông thường, chiến lược thử nghiệm không được kiểm tra. Hoặc, ai kiểm tra các bài kiểm tra?

Tóm lại, tôi quan tâm nhiều hơn đến bit "được điều khiển" trong TDD hơn là về bit "kiểm tra". Kiểm tra là hoàn toàn OK; những gì tôi không nhận được là lái thiết kế bằng cách thực hiện nó.

Tôi muốn xem câu trả lời có lý do tại sao TDD trong công nghệ phần mềm là một cách thực hành tốt và tại sao các vấn đề mà tôi đã giải thích ở trên không liên quan (hoặc không đủ liên quan) trong trường hợp phần mềm. Cảm ơn bạn.

Tôi nghĩ rằng có một quan niệm sai lầm ở đây. Trong thiết kế phần mềm, thiết kế rất gần với sản phẩm. Trong kỹ thuật dân dụng, kiến ​​trúc, thiết kế được tách rời khỏi sản phẩm thực tế: có những bản thiết kế giữ thiết kế, sau đó được vật chất hóa thành sản phẩm hoàn chỉnh, và chúng được tách ra bởi một lượng lớn thời gian và công sức.

TDD đang thử nghiệm thiết kế. Nhưng mỗi thiết kế xe hơi và thiết kế xây dựng cũng được thử nghiệm. Kỹ thuật xây dựng trước tiên được tính toán, sau đó được thử nghiệm ở quy mô nhỏ hơn, sau đó được thử nghiệm ở quy mô lớn hơn, trước khi đưa ra một tòa nhà thực sự. Khi họ phát minh ra dầm H và tải trọng chẳng hạn, hãy yên tâm rằng điều này đã được thử và thử lại trước khi họ thực sự xây dựng cây cầu đầu tiên với nó.

Thiết kế của ô tô cũng được thử nghiệm, bằng cách thiết kế các nguyên mẫu, và vâng, chắc chắn bằng cách điều chỉnh những thứ không chính xác, cho đến khi nó đáp ứng mong đợi. Một phần của quá trình này mặc dù chậm hơn, vì như bạn đã nói, bạn không thể loay hoay nhiều với sản phẩm. Nhưng mỗi thiết kế lại của một chiếc xe đều rút ra kinh nghiệm từ những người trước đây và mọi tòa nhà đều có khoảng một năm cơ bản đằng sau nó về tầm quan trọng của không gian, ánh sáng, cách nhiệt, sức mạnh, v.v. và trong thiết kế lại cho những cái mới hơn.

Ngoài ra, các bộ phận được thử nghiệm. Có lẽ không chính xác theo cùng một kiểu với phần mềm, nhưng các bộ phận cơ học (bánh xe, bộ đánh lửa, dây cáp) thường được đo và đặt dưới áp lực để biết kích thước là chính xác, không có bất thường nào được nhìn thấy, v.v. Chúng có thể bị xray hoặc laser- được đo, họ chạm vào các viên gạch để phát hiện ra những viên vỡ, chúng có thể thực sự được kiểm tra trong một số cấu hình này hoặc cấu hình khác hoặc chúng vẽ một đại diện giới hạn của một nhóm lớn để thực sự đưa nó vào thử nghiệm.

Đó là tất cả những điều bạn có thể áp dụng với TDD.

Và thực sự, thử nghiệm là không đảm bảo. Các chương trình gặp sự cố, ô tô bị hỏng và các tòa nhà bắt đầu làm những điều buồn cười khi gió thổi. Nhưng ... "an toàn" không phải là một câu hỏi boolean. Ngay cả khi bạn không bao giờ bao gồm tất cả mọi thứ, có thể bao gồm - nói - 99% các sự kiện vẫn tốt hơn là chỉ bao gồm 50%. Không thử nghiệm và sau đó phát hiện ra thép không ổn định và dễ gãy và gãy ngay lần đập búa đầu tiên khi bạn đưa lên cấu trúc chính của mình là một sự lãng phí tiền bạc. Rằng có những mối quan tâm khác vẫn có thể gây tổn hại cho tòa nhà, đừng làm cho nó bớt ngu ngốc hơn khi cho phép một lỗ hổng có thể phòng ngừa dễ dàng làm giảm thiết kế của bạn.

Đối với thực hành TDD, đó là vấn đề cân bằng. Chi phí thực hiện theo một cách (ví dụ, không thử nghiệm, và sau đó chọn các phần sau), so với chi phí thực hiện theo cách khác. Nó luôn luôn là một sự cân bằng. Nhưng đừng nghĩ rằng các quy trình thiết kế khác không có thử nghiệm và TDD.

IMO, hầu hết các câu chuyện thành công cho TDD là giả mạo và chỉ nhằm mục đích tiếp thị. Có thể có rất ít thành công với nó, nhưng chỉ cho các ứng dụng nhỏ. Tôi đang làm việc trên một ứng dụng Silverlight lớn, nơi các nguyên tắc TDD được sử dụng. Ứng dụng đã có hàng trăm bài kiểm tra nhưng vẫn không ổn định. Một số phần của ứng dụng không thể kiểm tra được do các tương tác người dùng phức tạp. Kết quả kiểm tra với rất nhiều giả và mã khó hiểu.

Ban đầu khi chúng tôi thử TDD, tất cả có vẻ tốt. Tôi đã có thể viết rất nhiều bài kiểm tra và chế nhạo những phần khó cho bài kiểm tra đơn vị. Khi bạn có một số lượng mã hợp lý và yêu cầu thay đổi giao diện, bạn sẽ bị lừa. Rất nhiều bài kiểm tra cần phải được sửa và bạn sẽ viết lại nhiều bài kiểm tra hơn thay đổi thực tế trong mã.

Peter Norvig Giải thích quan điểm của mình về TDD trong cuốn sách Coders At Work.

Seibel: Thế còn ý tưởng sử dụng các bài kiểm tra để lái thiết kế?

Norvig: Tôi thấy các bài kiểm tra nhiều hơn là một cách sửa lỗi hơn là cách thiết kế. Cách tiếp cận cực đoan này, nói Vâng, điều đầu tiên bạn làm là viết một bài kiểm tra nói rằng tôi nhận được câu trả lời đúng ở cuối, và sau đó bạn chạy nó và thấy rằng nó thất bại, và sau đó bạn nói, Tôi làm gì Cần gì tiếp theo? LỚN - đó dường như không phải là cách phù hợp để thiết kế một cái gì đó với tôi. Có vẻ như chỉ khi nó đơn giản đến mức giải pháp được đặt trước sẽ có ý nghĩa. Tôi nghĩ rằng bạn phải nghĩ về nó đầu tiên. Bạn phải nói rằng, những mảnh ghép là gì? Làm cách nào tôi có thể viết bài kiểm tra cho các mảnh cho đến khi tôi biết một số trong số chúng là gì? Sau đó, một khi bạn đã làm điều đó, thì đó là kỷ luật tốt để kiểm tra từng mảnh đó và hiểu rõ cách chúng tương tác với nhau và các trường hợp ranh giới và như vậy. Những người nên có tất cả các bài kiểm tra. Nhưng tôi không nghĩ bạn lái toàn bộ thiết kế bằng cách nói, Thử nghiệm này đã thất bại.

Test Driven Design hoạt động với tôi vì những lý do sau:

Nó là một hình thức runnable của đặc điểm kỹ thuật.

Điều này có nghĩa là bạn có thể thấy từ các trường hợp thử nghiệm:

1. RATNG mã được gọi là đầy đủ các đặc điểm kỹ thuật như các kết quả mong đợi có ngay trong các trường hợp thử nghiệm. Kiểm tra trực quan (dự kiến ​​các trường hợp kiểm tra sẽ vượt qua) có thể nói ngay "ồ, kiểm tra này kiểm tra việc gọi hóa đơn. Công ty đưa ra tình huống này, sẽ có kết quả THAT".
2. Làm thế nào mã được gọi. Các bước thực tế cần thiết để thực hiện các bài kiểm tra được chỉ định trực tiếp mà không có bất kỳ giàn giáo bên ngoài nào (cơ sở dữ liệu bị chế giễu, v.v.).

Bạn viết góc nhìn từ bên ngoài trước.

Mã thường được viết theo cách mà trước tiên bạn giải quyết vấn đề, và sau đó bạn nghĩ về cách mã bạn vừa viết sẽ được gọi. Điều này thường mang lại một giao diện khó xử vì việc "thêm cờ" thường dễ dàng hơn, v.v. Điều này sẽ cung cấp tính mô đun tốt hơn, vì mã sẽ được viết theo giao diện gọi, không phải theo cách khác.

Điều này thường sẽ dẫn đến mã sạch hơn đòi hỏi tài liệu giải thích ít hơn.

Bạn hoàn thành nhanh hơn

Vì bạn có thông số kỹ thuật trên biểu mẫu có thể chạy được, bạn đã hoàn thành khi bộ kiểm tra đầy đủ vượt qua. Bạn có thể thêm nhiều bài kiểm tra khi bạn làm rõ mọi thứ ở mức độ chi tiết hơn, nhưng theo nguyên tắc cơ bản, bạn có một chỉ số rất rõ ràng và rõ ràng về tiến trình và khi bạn hoàn thành.

Điều này có nghĩa là bạn có thể biết khi nào công việc có cần thiết hay không (nó có giúp vượt qua bài kiểm tra) mà cuối cùng bạn cần phải làm ít hơn.

Đối với những người suy ngẫm về nó có thể hữu ích cho họ, tôi khuyến khích bạn sử dụng TDD cho thói quen thư viện tiếp theo của bạn. Từ từ thiết lập một đặc tả kỹ thuật có thể chạy và làm cho mã vượt qua các bài kiểm tra. Khi hoàn tất, đặc tả kỹ thuật có thể chạy được dành cho tất cả những người cần xem cách gọi thư viện.

Nghiên cứu gần đây

"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. thời gian phát triển ban đầu sau khi áp dụng TDD. " ~ Kết quả và kinh nghiệm của 4 đội công nghiệp

Quá trình tạo phần mềm không phải là quá trình viết mã. Không có dự án phần mềm nào nên bắt đầu mà không có kế hoạch 'phạm vi rộng' trước. Giống như một dự án bắc cầu hai bờ sông cần một kế hoạch như vậy trước tiên.

Cách tiếp cận TDD liên quan (chủ yếu) đến kiểm thử đơn vị - ít nhất đó là cách mọi người có xu hướng nghĩ về nó - đó là tạo ra các bit phần mềm cấp thấp nhất. Khi tất cả các tính năng và hành vi đã được xác định và chúng tôi thực sự biết những gì chúng tôi muốn đạt được.

Trong kỹ thuật kết cấu có vẻ như thế này:

'Chúng ta có hai mảnh kim loại này được kết nối với nhau và kết nối cần duy trì lực cắt theo thứ tự x. Hãy thử xem phương thức kết nối nào là phương pháp tốt nhất để thực hiện điều này '

Để kiểm tra nếu phần mềm hoạt động tổng thể, chúng tôi thiết kế các loại kiểm tra khác như kiểm tra khả năng sử dụng, kiểm tra tích hợp và kiểm tra chấp nhận. Những điều này cũng nên được xác định trước khi công việc thực tế viết mã bắt đầu và được thực hiện sau khi các bài kiểm tra đơn vị có màu xanh lá cây.

Xem Mô hình V: http://en.wikipedia.org/wiki/V-Model_%28software_development%29

Hãy xem cách nó hoạt động cho một cây cầu:

1. Một chính quyền địa phương nói với một công ty xây dựng cầu: "Chúng tôi cần một cây cầu để kết nối hai điểm này. Cây cầu cần có khả năng cho phép n lưu lượng truy cập mỗi giờ và sẵn sàng cho ngày 21 tháng 12 năm 2012 '- đây là định nghĩa về kiểm tra chấp nhận. Công ty sẽ không nhận được đủ số tiền (hoặc bất kỳ), nếu họ không thể vượt qua bài kiểm tra đó.

2. Quản lý công ty quyết định tiến độ dự án. Họ thành lập các nhóm làm việc và thiết lập mục tiêu cho mỗi nhóm. Nếu các đội sẽ không đáp ứng các mục tiêu này - cây cầu sẽ không được xây dựng đúng thời gian. Tuy nhiên - có một số mức độ linh hoạt ở đây. Nếu một trong các đội có một số vấn đề, công ty có thể bù đắp điều đó bằng cách thay đổi yêu cầu, thay đổi nhà thầu phụ, thuê thêm người, v.v ... để toàn bộ dự án vẫn đáp ứng mục tiêu được đặt ra ở điểm # 1.

3. Trong một nhóm chịu trách nhiệm thiết kế các thành phần cầu cụ thể, nó trông giống như trong ví dụ tôi đã đưa ra ở trên. Đôi khi giải pháp là hiển nhiên, bởi vì chúng tôi có khối lượng kiến ​​thức lớn về việc xây dựng các cây cầu (nó giống như sử dụng một thư viện được thử nghiệm tốt trong phát triển phần mềm - bạn chỉ cho rằng nó hoạt động như quảng cáo). Đôi khi bạn cần tạo ra một số thiết kế và kiểm tra chúng để chọn ra thiết kế tốt nhất. Tuy nhiên, các tiêu chí mà thành phần được kiểm tra đã được biết trước.

Trong tâm trí tôi TDD hoạt động vì

• Nó buộc bạn xác định những gì bạn muốn đơn vị thực hiện trước khi quyết định triển khai ở mức độ chính xác thường không được bao phủ bởi bất kỳ thông số kỹ thuật hoặc yêu cầu nào
• Nó làm cho mã của bạn vốn có thể sử dụng lại được, bởi vì bạn phải sử dụng nó trong cả hai kịch bản thử nghiệm và sản xuất
• Nó khuyến khích bạn viết mã trong trình phục hồi nhỏ hơn để kiểm tra các đoạn có xu hướng dẫn đến các thiết kế tốt hơn

Cụ thể về điểm bạn nâng

• Mã dễ uốn hơn gạch hoặc thép, vì vậy rẻ hơn để sửa đổi. Vẫn rẻ hơn nếu bạn có các xét nghiệm để đảm bảo hành vi không thay đổi
• TDD không phải là một cái cớ để không thiết kế - một kiến ​​trúc cấp cao nói chung vẫn được khuyên, chỉ là không có quá nhiều chi tiết. Big Up Front Design không được khuyến khích, nhưng việc thiết kế vừa đủ được khuyến khích
• TDD không thể đảm bảo một hệ thống hoạt động, nhưng nó ngăn ngừa rất nhiều lỗi nhỏ xảy ra nếu không sẽ bị bỏ qua. Ngoài ra bởi vì nó thường khuyến khích mã bao thanh toán tốt hơn nên thường dễ hiểu hơn nên ít có khả năng bị lỗi

TL; DR

Lập trình vẫn là một hoạt động thiết kế, nó không phải là xây dựng. Viết các bài kiểm tra đơn vị sau khi thực tế chỉ xác nhận rằng mã thực hiện những gì nó làm, không phải là nó làm một cái gì đó hữu ích. Thất bại thử nghiệm là giá trị thực sự bởi vì chúng cho phép bạn bắt lỗi sớm.

Mã là thiết kế

Trong Chương 7 của PPP, "Chú Bob" nói trực tiếp về vấn đề này. Ngay từ đầu chương, ông đã tham khảo một bài viết xuất sắc của Jack Reeves, trong đó ông đề xuất rằng mã là thiết kế (liên kết đến một trang thu thập cả ba bài viết của ông về chủ đề này).

Điều thú vị về lập luận này là ông chỉ ra, không giống như các ngành kỹ thuật khác, nơi xây dựng là một hoạt động rất tốn kém, việc xây dựng phần mềm tương đối miễn phí (nhấn vào biên dịch trong IDE của bạn và bạn có phần mềm được xây dựng của bạn). Nếu bạn xem viết mã như một hoạt động thiết kế thay vì hoạt động xây dựng, thì chu trình tái cấu trúc đỏ-xanh về cơ bản là một bài tập trong thiết kế. Thiết kế của bạn phát triển khi bạn viết các bài kiểm tra, mã để đáp ứng chúng và tái cấu trúc để tích hợp mã mới vào hệ thống hiện có.

TDD như Đặc điểm kỹ thuật

Các bài kiểm tra đơn vị mà bạn viết cho TDD là bản dịch trực tiếp của đặc tả khi bạn hiểu chúng. Bằng cách viết mã thỏa mãn tối thiểu thông số kỹ thuật của bạn (làm cho các thử nghiệm của bạn chuyển sang màu xanh lá cây), tất cả các mã bạn đã viết đều có ở đó cho một mục đích cụ thể. Liệu mục đích đó có được đáp ứng hay không được xác nhận bằng một thử nghiệm lặp lại.

Viết bài kiểm tra cho các chức năng

Một lỗi phổ biến trong kiểm thử đơn vị xảy ra khi bạn viết các bài kiểm tra sau mã, cuối cùng bạn kiểm tra xem mã đó có làm được không. Nói cách khác, bạn sẽ thấy các bài kiểm tra như thế này

public class PersonTest:Test
{
   [Test]
   TestNameProperty()
   {
      var person=new Person();
      person.Name="John Doe";
      Assert.AreEqual("John Doe", person.Name);
   }
}

Trong khi tôi đoán mã này có thể hữu ích (đảm bảo rằng ai đó đã không làm điều gì đó tục tĩu với một thuộc tính đơn giản). Nó không phục vụ để xác nhận một đặc điểm kỹ thuật. Và như bạn đã nói, viết các loại bài kiểm tra này chỉ đưa bạn đến nay.

Trong khi Màu xanh lá cây là giá trị dối trá màu đỏ, tôi đã có khoảnh khắc "aha" thực sự đầu tiên của mình ở TDD khi tôi gặp một thử nghiệm bất ngờ. Tôi đã có một bộ các bài kiểm tra mà tôi đã có cho một khung mà tôi đang xây dựng. Thêm một tính năng mới, tôi đã viết một bài kiểm tra cho nó. Sau đó viết mã để thực hiện bài kiểm tra vượt qua. Biên dịch, kiểm tra ... có màu xanh trong bài kiểm tra mới. Nhưng cũng có một màu đỏ trong một bài kiểm tra khác mà tôi không mong đợi là màu đỏ.

Nhìn vào thất bại, tôi thở phào nhẹ nhõm vì tôi nghi ngờ mình sẽ bắt được con bọ đó trong một thời gian nếu tôi không có bài kiểm tra đó. Và đó là một lỗi RẤT khó chịu. May mắn thay, tôi đã có bài kiểm tra, và nó cho tôi biết chính xác những gì tôi cần làm để sửa lỗi. Nếu không có thử nghiệm, tôi sẽ tiếp tục xây dựng hệ thống của mình (với lỗi lây nhiễm các mô-đun khác phụ thuộc vào mã đó) và vào thời điểm lỗi được phát hiện, việc khắc phục nó là một nhiệm vụ chính.

Lợi ích thực sự của TDD là nó cho phép chúng tôi thực hiện các thay đổi với sự từ bỏ liều lĩnh. Nó giống như một mạng lưới an toàn để lập trình. Hãy nghĩ về những gì sẽ xảy ra nếu một nghệ sĩ hình thang mắc lỗi và ngã. Với mạng, đó là một sai lầm ngượng ngùng. Không, đó là một bi kịch. Cùng quan điểm, TDD cứu bạn khỏi biến những sai lầm đau đầu thành thảm họa giết chết dự án.

Bạn sẽ không tìm thấy bất cứ ai ủng hộ Phát triển hướng thử nghiệm, hoặc thậm chí là Thiết kế hướng thử nghiệm (chúng khác nhau), cho biết các thử nghiệm chứng minh các ứng dụng. Vì vậy, hãy gọi đó là một người đàn ông rơm và được thực hiện.

Bạn sẽ không tìm thấy bất cứ ai không thích hoặc không ấn tượng với TDD nói rằng Bài kiểm tra là một sự lãng phí thời gian và công sức. Mặc dù các bài kiểm tra không chứng minh được các ứng dụng, nhưng chúng khá hữu ích trong việc tìm lỗi.

Với hai điều đã nói, không bên nào làm được điều gì khác biệt liên quan đến việc thực sự kiểm tra phần mềm. Cả hai đang làm thử nghiệm. Cả hai đều tin tưởng vào việc thử nghiệm để tìm ra càng nhiều lỗi càng tốt và cả hai đều sử dụng các thử nghiệm để xác minh rằng một chương trình phần mềm đang hoạt động tốt như có thể được phát hiện tại thời điểm đó. Không ai có một nửa đầu mối bán phần mềm mà không kiểm tra và không ai có một nửa đầu mối mong đợi rằng thử nghiệm sẽ đưa ra mã mà họ bán hoàn toàn không có lỗi.

Vì vậy, sự khác biệt giữa TDD và không-TDD không phải là các bài kiểm tra đang được thực hiện. Sự khác biệt là khi các bài kiểm tra được viết. Trong các bài kiểm tra TDD được viết TRƯỚC KHI phần mềm. Trong các bài kiểm tra không TDD được viết sau hoặc phối hợp với phần mềm.

Vấn đề tôi gặp phải liên quan đến vấn đề thứ hai là việc kiểm tra sau đó có xu hướng nhắm mục tiêu phần mềm được viết nhiều hơn kết quả hoặc thông số kỹ thuật mong muốn. Ngay cả khi nhóm thử nghiệm tách biệt với nhóm phát triển, nhóm thử nghiệm có xu hướng xem xét phần mềm, chơi với nó và viết các thử nghiệm nhắm mục tiêu vào nó.

Một điều được chú ý hết lần này đến lần khác bởi những người nghiên cứu thành công dự án, đó là tần suất khách hàng sẽ đưa ra những gì họ muốn, những người phát triển chạy đi và viết một cái gì đó, và khi họ quay lại với khách hàng nói "xong" nó hóa ra là hoàn toàn và hoàn toàn KHÔNG phải những gì khách hàng yêu cầu. "Nhưng nó vượt qua tất cả các bài kiểm tra ..."

Mục tiêu của TDD là phá vỡ "đối số vòng tròn" này và cung cấp cơ sở cho các thử nghiệm kiểm tra phần mềm không phải là chính phần mềm. Các bài kiểm tra được viết để nhắm vào hành vi mà "khách hàng" muốn. Phần mềm sau đó được viết để vượt qua các bài kiểm tra.

TDD là một phần của giải pháp nhằm giải quyết vấn đề này. Đây không phải là bước duy nhất bạn thực hiện. Những việc khác bạn cần làm là đảm bảo có nhiều phản hồi của khách hàng và thường xuyên hơn.

Theo kinh nghiệm của tôi, TDD là một điều rất khó để thực hiện thành công. Thật khó để có được các bài kiểm tra được viết trước khi có một sản phẩm bởi vì rất nhiều thử nghiệm tự động đòi hỏi phải có một cái gì đó để chơi để làm cho phần mềm tự động hoạt động tốt. Thật khó để có được các nhà phát triển không quen với thử nghiệm đơn vị để làm điều đó. Hết lần này đến lần khác tôi đã nói với mọi người trong nhóm của mình viết các bài kiểm tra ĐẦU TIÊN. Tôi chưa bao giờ thực sự có được một cái để làm điều đó. Cuối cùng, những hạn chế về thời gian và chính trị đã phá hủy mọi nỗ lực để chúng tôi thậm chí không làm các bài kiểm tra đơn vị nữa. Điều này tất nhiên dẫn đến việc thiết kế được vô tình và kết hợp chặt chẽ để ngay cả khi chúng ta muốn, bây giờ nó sẽ rất tốn kém để thực hiện. Tránh THAT là những gì TDD cuối cùng cung cấp cho các nhà phát triển.

Thiết kế đầu tiên

TDD không phải là một cái cớ để bỏ qua thiết kế. Tôi đã thấy nhiều người nhảy vào nhóm "nhanh nhẹn" bởi vì họ mặc dù họ có thể bắt đầu mã hóa ngay lập tức. Nhanh nhẹn thực sự sẽ giúp bạn mã hóa nhanh hơn nhiều so với các thực hành tốt về kỹ thuật (lĩnh vực khác) đã truyền cảm hứng cho quá trình thác nước.

Nhưng kiểm tra sớm

Khi người ta nói rằng bài kiểm tra đang lái thiết kế, điều đó chỉ có nghĩa là người ta có thể sử dụng các bài kiểm tra rất sớm trong giai đoạn thiết kế, rất lâu trước khi nó hoàn thành. Thực hiện các thử nghiệm này sẽ ảnh hưởng mạnh đến thiết kế của bạn bằng cách thách thức các khu vực màu xám và đọ sức với thế giới thực từ lâu trước khi sản phẩm được hoàn thành. buộc bạn phải thường xuyên quay lại thiết kế và điều chỉnh nó để tính đến điều này.

Kiểm tra và thiết kế ... một và giống nhau

Theo tôi, TDD chỉ đơn giản đưa thử nghiệm trở thành một phần không thể thiếu trong thiết kế thay vì một cái gì đó được thực hiện ở cuối để xác nhận nó. Khi bạn bắt đầu sử dụng TDD, bạn càng có nhiều suy nghĩ về cách phá hủy / phá vỡ hệ thống của bạn khi bạn thiết kế nó. Cá nhân tôi không phải lúc nào cũng làm bài kiểm tra của mình trước. Chắc chắn tôi thực hiện các thử nghiệm (đơn vị) rõ ràng trên một giao diện nhưng lợi ích thực sự đến từ các thử nghiệm tích hợp và đặc tả mà tôi tạo ra khi tôi nghĩ về một cách mới và sáng tạo mà thiết kế này có thể phá vỡ. Ngay khi tôi nghĩ ra một cách, tôi viết mã kiểm tra cho nó và xem điều gì sẽ xảy ra. Đôi khi tôi có thể sống với hậu quả, trong trường hợp này tôi di chuyển thử nghiệm trong một dự án riêng không phải là một phần của bản dựng chính (vì nó sẽ tiếp tục thất bại).

Rồi ai lái chương trình?

Trong TDD, điều khiển ở đây chỉ đơn giản có nghĩa là các bài kiểm tra của bạn ảnh hưởng mạnh mẽ đến thiết kế của bạn đến nỗi người ta có thể cảm thấy họ đang thực sự lái nó. Tuy nhiên, điều đó dừng lại ở đó, và ở đây tôi hiểu mối quan tâm của bạn, nó hơi đáng sợ ... ai là người điều khiển chương trình?

BẠN đang lái xe, không phải các bài kiểm tra. Các bài kiểm tra ở đó để khi bạn di chuyển dọc theo bạn sẽ có được một mức độ tự tin tốt về những gì bạn đã tạo ra, do đó cho phép bạn xây dựng thêm khi biết nó nằm trên cơ sở vững chắc.

rắn miễn là các bài kiểm tra là rắn

Chính xác , do đó thúc đẩy trong TDD. Nó không phải là quá nhiều các bài kiểm tra đang thúc đẩy toàn bộ, nhưng chúng sẽ có ảnh hưởng sâu sắc đến cách bạn làm mọi thứ, về cách bạn thiết kế và nghĩ rằng hệ thống của bạn mà bạn sẽ ủy thác một phần lớn quá trình suy nghĩ của bạn để kiểm tra và đổi lại họ sẽ có ảnh hưởng sâu sắc đến thiết kế của bạn.

Vâng, nhưng nếu tôi làm điều đó với cây cầu của tôi ....

dừng lại ở đó ... kỹ thuật phần mềm RẤT khác với bất kỳ thực hành kỹ thuật nào khác ngoài kia. Trong thực tế kỹ thuật phần mềm thực sự có nhiều điểm chung với văn học. Người ta có thể lấy một cuốn sách đã hoàn thành, trích xuất 4 chương từ đó và viết hai chương mới để thay thế chúng dán lại vào cuốn sách và bạn vẫn có một cuốn sách hay. Với các bài kiểm tra và phần mềm tốt, bạn có thể trích xuất bất kỳ phần nào trong hệ thống của mình và thay thế nó bằng phần khác và chi phí thực hiện không cao hơn nhiều so với việc tạo ra nó ở nơi đầu tiên. Trên thực tế, nếu bạn đã thực hiện các thử nghiệm của mình và cho phép chúng ảnh hưởng đến thiết kế của bạn đủ thì nó có thể rẻ hơn so với việc tạo ra nó ngay từ đầu vì bạn sẽ có một mức độ tin cậy nhất định rằng sự thay thế này sẽ không phá vỡ những gì các thử nghiệm đang che đậy.

Nếu nó tốt như vậy thì sao nó không hoạt động?

Bởi vì thử nghiệm đòi hỏi một tư duy RẤT khác với xây dựng. Không phải ai cũng có thể chuyển đổi trở lại, từ thực tế, một số người sẽ không thể xây dựng các bài kiểm tra phù hợp đơn giản chỉ vì họ không thể đặt tâm trí để phá hủy sự sáng tạo của họ. Điều này sẽ mang lại các dự án với quá ít thử nghiệm hoặc thử nghiệm vừa đủ để đạt được số liệu mục tiêu (phạm vi bảo hiểm mã xuất hiện trong tâm trí). Họ sẽ vui vẻ kiểm tra đường dẫn và kiểm tra ngoại lệ nhưng sẽ quên đi các trường hợp góc và điều kiện biên.

Những người khác sẽ chỉ dựa vào các thử nghiệm để thiết kế một phần hoặc hoàn toàn. Mỗi thành viên làm điều đó sau đó tích hợp với nhau. Thiết kế trước hết là một công cụ giao tiếp, các cổ phần chúng tôi đặt dưới đất để nói rằng đây là nơi tôi sẽ đến, các bản phác thảo nói rằng đây là nơi các cửa ra vào và cửa sổ sẽ ở đó. Nếu không có điều này, phần mềm của bạn sẽ bị tiêu diệt bất kể bạn đặt bao nhiêu bài kiểm tra. Tích hợp và sáp nhập sẽ luôn luôn đau đớn và họ sẽ thiếu các bài kiểm tra ở mức độ trừu tượng cao nhất.

Tor các đội TDD có thể không phải là con đường để đi.

Với TDD, bạn có xu hướng không viết mã không dễ dàng hoặc nhanh chóng để kiểm tra. Điều này có vẻ như là một điều nhỏ, nhưng nó có thể có ảnh hưởng sâu sắc đến một dự án vì nó ảnh hưởng đến việc dễ dàng tái cấu trúc, kiểm tra, tái tạo lỗi bằng các kiểm tra và xác minh sửa lỗi.

Nhà phát triển mới trong dự án cũng dễ dàng tăng tốc hơn khi bạn có mã bao thanh toán tốt hơn được hỗ trợ bởi các thử nghiệm.

Tôi đã suy nghĩ về điều này rất nhiều, mặc dù bản thân tôi không thực hành TDD nhiều như vậy. Dường như có một mối tương quan tích cực (mạnh?) Giữa chất lượng mã và theo TDD.

1) Điều đầu tiên của tôi là, điều này (chủ yếu) không phải do TDD thêm "chất lượng tốt hơn" vào mã (như vậy), giống như TDD giúp loại bỏ những phần và thói quen xấu nhất, và do đó gián tiếp tăng chất lượng.

Tôi thậm chí sẽ ủng hộ rằng đó không phải là bản thân bài kiểm tra - đó là quá trình viết những bài kiểm tra đó. Thật khó để viết các bài kiểm tra cho một mã xấu và ngược lại. Và giữ điều này ở phía sau đầu trong khi lập trình, loại bỏ rất nhiều mã xấu.

2) Một quan điểm khác (điều này đang trở nên triết lý) là theo thói quen tinh thần của chủ. Bạn không học cách trở thành bậc thầy bằng cách làm theo "thói quen bên ngoài" của anh ấy (như, râu dài là tốt), bạn phải học cách suy nghĩ nội tâm của anh ấy, và điều này thật khó. Và bằng cách nào đó, các lập trình viên (người mới) làm theo TDD, sắp xếp cách suy nghĩ của họ gần với những người làm chủ hơn.

Phương pháp "viết thử + tái cấu trúc cho đến khi vượt qua" trông cực kỳ phản kỹ thuật.

Bạn dường như có một quan niệm sai lầm về cả tái cấu trúc và TDD.

Tái cấu trúc mã là quá trình thay đổi mã nguồn của chương trình máy tính mà không sửa đổi hành vi chức năng bên ngoài của nó để cải thiện một số thuộc tính không chức năng của phần mềm.

Vì vậy, bạn không thể cấu trúc lại mã cho đến khi nó đi qua.

Và TDD, cụ thể là thử nghiệm đơn vị (mà tôi xem là cải tiến cốt lõi, vì thử nghiệm khác có vẻ khá hợp lý đối với tôi), không phải là về thiết kế lại một thành phần cho đến khi nó hoạt động. Đó là về thiết kế một thành phần và thực hiện triển khai cho đến khi thành phần đó hoạt động như thiết kế.

Ngoài ra, điều quan trọng là phải thực sự nắm bắt, thử nghiệm đơn vị đó là về các đơn vị thử nghiệm . Do xu hướng luôn luôn viết rất nhiều thứ từ đầu, điều quan trọng là phải kiểm tra các đơn vị như vậy. Một kỹ sư dân sự đã biết thông số kỹ thuật của các đơn vị anh ta sử dụng (các vật liệu khác nhau) và có thể mong đợi chúng hoạt động. Đây là hai điều thường không áp dụng cho các kỹ sư phần mềm và rất kỹ thuật để kiểm tra các đơn vị trước khi sử dụng chúng, bởi vì điều đó có nghĩa là sử dụng các thành phần chất lượng cao đã được kiểm tra.
Nếu một kỹ sư dân sự có ý tưởng sử dụng một số mô sợi mới để làm mái che sân vận động, bạn sẽ mong đợi anh ta thử nghiệm nó như một đơn vị, tức là xác định các thông số kỹ thuật cần thiết (ví dụ: trọng lượng, tính thấm, độ ổn định, v.v.) và Sau đó kiểm tra và tinh chỉnh nó cho đến khi nó gặp họ.

Đó là lý do tại sao TDD hoạt động. Bởi vì nếu bạn xây dựng phần mềm của các đơn vị được thử nghiệm, rất có thể nó hoạt động tốt hơn, khi bạn cắm chúng lại với nhau và nếu không, bạn có thể mong đợi vấn đề nằm trong mã keo của mình, giả sử các thử nghiệm của bạn có độ bao phủ tốt.

chỉnh sửa:
Tái cấu trúc có nghĩa là: không thay đổi chức năng. Một điểm của bài kiểm tra đơn vị là đảm bảo rằng việc tái cấu trúc không phá vỡ mã. Vì vậy, TDD có nghĩa là để đảm bảo rằng tái cấu trúc không có tác dụng phụ.
Độ chi tiết không phải là một chủ đề của phối cảnh, vì như tôi đã nói, đơn vị kiểm tra các đơn vị kiểm tra và không phải hệ thống, theo đó độ chi tiết được xác định chính xác.

TDD khuyến khích kiến ​​trúc tốt. Nó đòi hỏi bạn phải xác định và triển khai các thông số kỹ thuật cho tất cả các đơn vị của mình, buộc bạn phải thiết kế chúng trước khi thực hiện, điều này hoàn toàn trái ngược với những gì bạn nghĩ. TDD ra lệnh tạo ra các đơn vị, có thể được kiểm tra riêng lẻ và do đó hoàn toàn tách rời.
TDD không có nghĩa là tôi ném một bài kiểm tra phần mềm vào mã spaghetti và khuấy mì cho đến khi nó qua.

Trái ngược với kỹ thuật dân dụng, trong công nghệ phần mềm, một dự án thường không ngừng phát triển. Trong kỹ thuật dân dụng, bạn có yêu cầu xây dựng một cây cầu ở vị trí A, có thể mang x tấn và đủ rộng cho n phương tiện mỗi giờ.
Trong công nghệ phần mềm, khách hàng về cơ bản có thể quyết định tại bất kỳ thời điểm nào (có thể sau khi hoàn thành), anh ta muốn một cây cầu đôi, và anh ta muốn nó được kết nối với đường cao tốc gần nhất, và anh ta muốn nó là một cây cầu nâng, bởi vì công ty của anh ta gần đây bắt đầu sử dụng tàu thuyền.
Kỹ sư phần mềm được giao nhiệm vụ thay đổi thiết kế. Không phải vì thiết kế của họ là thiếu sót, mà bởi vì đó là modus operandi. Nếu phần mềm được thiết kế tốt, nó có thể được thiết kế lại ở mức cao, mà không phải viết lại tất cả các thành phần cấp thấp.

TDD là về xây dựng phần mềm với các thành phần được phân tách riêng, được thử nghiệm cao. Được thực hiện tốt, nó sẽ giúp bạn đáp ứng các thay đổi trong yêu cầu một cách nhanh chóng và an toàn hơn là không có.

TDD bổ sung các yêu cầu cho quy trình phát triển, nhưng nó không cấm bất kỳ phương pháp đảm bảo chất lượng nào khác. Cấp, TDD không cung cấp bảo mật giống như xác minh chính thức, nhưng một lần nữa, xác minh chính thức cực kỳ tốn kém và không thể sử dụng ở cấp độ hệ thống. Tuy nhiên, nếu bạn muốn, bạn có thể kết hợp cả hai.

TDD cũng bao gồm các bài kiểm tra khác với bài kiểm tra đơn vị, được thực hiện ở cấp hệ thống. Tôi thấy những điều này dễ giải thích nhưng khó thực hiện và khó đo lường. Ngoài ra, chúng khá hợp lý. Mặc dù tôi hoàn toàn thấy sự cần thiết của chúng, tôi không thực sự coi chúng là ý tưởng.

Cuối cùng, không có công cụ nào thực sự giải quyết được vấn đề. Công cụ chỉ làm cho việc giải quyết một vấn đề dễ dàng hơn. Bạn có thể hỏi: Làm thế nào một cái đục sẽ giúp tôi với kiến ​​trúc tuyệt vời? Vâng, nếu bạn có kế hoạch làm tường thẳng, gạch thẳng là giúp đỡ. Và đúng vậy, nếu bạn đưa công cụ đó cho một thằng ngốc, cuối cùng anh ta có thể sẽ đập nó qua chân anh ta, nhưng đó không phải là lỗi của đục, vì nó không phải là một lỗ hổng của TDD mà nó mang lại sự bảo mật sai cho người mới, người không viết bài kiểm tra tốt
Vì vậy, ở điểm mấu chốt, người ta có thể nói TDD hoạt động tốt hơn nhiều so với không có TDD.

Tôi không thích câu nói của bạn, 'bài kiểm tra, thay vì người dùng, đặt ra yêu cầu'. Tôi nghĩ rằng bạn chỉ đang xem xét thử nghiệm đơn vị trong TDD, trong khi nó cũng bao gồm thử nghiệm tích hợp.

Ngoài việc kiểm tra các thư viện tạo nên cơ sở của phần mềm, hãy viết các bài kiểm tra bao gồm các tương tác mà người dùng của bạn có với phần mềm / trang web / bất cứ điều gì. Chúng đến trực tiếp từ người dùng và các thư viện như dưa chuột (http://cukes.info) thậm chí có thể cho phép người dùng của bạn tự viết các bài kiểm tra bằng ngôn ngữ tự nhiên.

TDD cũng khuyến khích tính linh hoạt trong mã - nếu bạn dành mãi mãi để thiết kế kiến ​​trúc của một thứ gì đó, sẽ rất khó để thực hiện những thay đổi đó sau này nếu cần thiết. Bắt đầu với việc viết một vài bài kiểm tra, sau đó viết một ít mã vượt qua các bài kiểm tra đó. Thêm nhiều bài kiểm tra, thêm mã. Nếu bạn cần thay đổi hoàn toàn mã, các thử nghiệm của bạn vẫn đứng vững.

Và không giống như cầu và xe hơi, một mảnh duy nhất của phần mềm có thể trải qua những thay đổi lớn trong cuộc đời của mình, và làm refactoring phức tạp mà không cần phải xét nghiệm bằng văn bản đầu tiên chỉ được hỏi cho các rắc rối.

Tôi nghĩ rằng bạn đang tiếp cận điểm đầu tiên từ góc độ sai.

Từ quan điểm lý thuyết, chúng tôi đang chứng minh rằng một cái gì đó hoạt động bằng cách kiểm tra chống lại các điểm thất bại. Đó là phương pháp được sử dụng. Có thể có nhiều cách khác để bạn chứng minh rằng một cái gì đó có chức năng, nhưng TDD đã tự thiết lập do cách đơn giản của phương pháp bit-khôn ngoan: nếu nó không phá vỡ nó hoạt động.

Trong thực tế, điều này chỉ đơn giản chuyển thành: bây giờ chúng ta có thể chuyển sang điều tiếp theo (sau khi chúng ta đã áp dụng thành công TDD để đáp ứng tất cả các vị từ). Nếu bạn tiếp cận TDD từ góc độ này, thì đó không phải là "viết bài kiểm tra + tái cấu trúc cho đến khi vượt qua", đó là về việc hoàn thành việc này, giờ đây tôi hoàn toàn tập trung vào tính năng tiếp theo là điều quan trọng nhất hiện nay .

Hãy nghĩ làm thế nào điều này áp dụng cho kỹ thuật dân dụng. Chúng tôi đang xây dựng một sân vận động có thể chứa khán giả công cộng gồm 150000 người. Sau khi chúng tôi chứng minh rằng tính toàn vẹn cấu trúc của sân vận động là âm thanh, chúng tôi đã hài lòng trước . Bây giờ chúng ta có thể tập trung vào các vấn đề khác trở nên quan trọng ngay lập tức, chẳng hạn như nhà vệ sinh, quầy thức ăn, chỗ ngồi, v.v ... làm cho trải nghiệm của khán giả trở nên dễ chịu hơn. Đây là một sự đơn giản hóa, vì có nhiều hơn với TDD, nhưng điểm mấu chốt là bạn không tạo ra trải nghiệm người dùng đáng nguyền rủa nhất nếu bạn tập trung vào các tính năng mới và thú vị và duy trì tính toàn vẹn cùng một lúc. Bạn có được nó một nửa trong cả hai trường hợp. Ý tôi là, làm thế nào bạn có thể biết chính xác làm thế nào nhiều nhà vệ sinh và bạn nên đặt chỗ nào cho 150000 người? Tôi hiếm khi thấy các sân vận động sụp đổ trong đời mình, nhưng tôi đã phải xếp hàng chờ đợi trong suốt nửa thời gian trong rất nhiều dịp. Điều đó nói rằng vấn đề nhà vệ sinh phức tạp hơn nhiều và nếu các kỹ sư có thể dành ít thời gian hơn cho sự an toàn, cuối cùng họ có thể giải quyết vấn đề nhà vệ sinh.

Điểm thứ hai của bạn là không liên quan, bởi vì chúng tôi đã đồng ý rằng tuyệt đối là một nỗ lực ngu ngốc và bởi vì Hank Moody nói rằng chúng không tồn tại (nhưng tôi dường như không thể tìm thấy một tài liệu tham khảo cho điều đó).

TDD trong công nghệ phần mềm là một cách thực hành tốt, giống như xử lý lỗi trong các ứng dụng là cách thực hành tốt cũng như ghi nhật ký và chẩn đoán (mặc dù đó là một phần của việc xử lý lỗi).

TDD không được sử dụng như một công cụ để giảm sự phát triển phần mềm thành mã hóa thử nghiệm & lỗi. Tuy nhiên, hầu hết các lập trình viên nhìn chằm chằm vào nhật ký thời gian chạy, xem các ngoại lệ trong trình gỡ lỗi hoặc sử dụng các dấu hiệu thất bại / thành công khác trong giai đoạn phát triển của họ bao gồm mã hóa / biên dịch / chạy ứng dụng - cả ngày.

TDD chỉ là một cách để chính thức hóa và tự động hóa các bước đó để giúp bạn trở thành nhà phát triển hiệu quả hơn.

1) Bạn không thể so sánh công nghệ phần mềm với xây dựng cầu, tính linh hoạt trong xây dựng cầu không giống với thiết kế chương trình phần mềm. Xây dựng cây cầu giống như viết đi viết lại cùng một chương trình thành một cỗ máy mất mát. Cầu không thể được nhân đôi và tái sử dụng như phần mềm có thể. Mỗi cây cầu là duy nhất và phải được sản xuất. Điều tương tự cũng xảy ra với xe hơi và các thiết kế khác.

Điều khó nhất trong công nghệ phần mềm là tái tạo lỗi, khi một cây cầu bị hỏng thường rất dễ xác định điều gì đã sai và về mặt lý thuyết thì dễ dàng tái tạo lỗi. Khi một chương trình máy tính bị lỗi, nó có thể là một chuỗi các sự kiện phức tạp khiến hệ thống rơi vào trạng thái bị lỗi và rất khó để xác định lỗi ở đâu. TDD và kiểm tra đơn vị giúp dễ dàng kiểm tra tính mạnh mẽ của các thành phần, thư viện và thuật toán phần mềm.

2) Sử dụng các bài kiểm tra đơn vị yếu và các trường hợp kiểm tra nông không gây căng thẳng cho hệ thống để xây dựng cảm giác tự tin sai lầm chỉ là thực tiễn tồi. Bỏ qua chất lượng kiến ​​trúc của một hệ thống và chỉ hoàn thành các thử nghiệm tất nhiên là xấu. Nhưng gian lận tại nơi xây dựng một tòa nhà chọc trời hoặc một cây cầu để tiết kiệm vật liệu và không tuân theo các bản thiết kế là điều tồi tệ và nó xảy ra mọi lúc ...

Nếu bạn chấp nhận rằng các lỗi được tìm thấy càng sớm thì chi phí sửa chữa chúng càng ít, thì điều đó một mình làm cho TDD trở nên đáng giá.

TDD không thực sự về thử nghiệm. Và nó chắc chắn không phải là một sự thay thế cho thử nghiệm tốt. Những gì nó mang lại cho bạn là một thiết kế được thiết kế chu đáo , dễ tiêu dùng và dễ bảo trì và tái cấu trúc sau này. Những điều đó lần lượt dẫn đến ít lỗi hơn và thiết kế phần mềm tốt hơn, dễ thích nghi hơn. TDD cũng giúp bạn suy nghĩ thấu đáo và ghi lại các giả định của bạn, thường thấy rằng một số trong số chúng không chính xác. Bạn tìm thấy những điều này rất sớm trong quá trình.

Và như một lợi ích phụ, bạn có một bộ thử nghiệm lớn mà bạn có thể chạy để đảm bảo rằng phép tái cấu trúc không thay đổi hành vi (đầu vào và đầu ra) của phần mềm của bạn.

Tôi sẽ cho bạn một câu trả lời ngắn gọn. Thông thường TDD được nhìn sai cách giống như thử nghiệm đơn vị. Tôi chưa bao giờ hiểu thử nghiệm đơn vị cho đến gần đây sau khi xem một video nói chuyện công nghệ tốt. Về cơ bản TDD chỉ nói rằng bạn muốn những điều sau đây LÀM VIỆC. Họ PHẢI được thực hiện. Sau đó, bạn thiết kế phần còn lại của phần mềm theo cách bạn thường làm.

Nó giống như viết trường hợp sử dụng cho một thư viện trước khi thiết kế thư viện. Ngoại trừ bạn có thể thay đổi trường hợp sử dụng trong thư viện và bạn có thể không dùng TDD (Tôi sử dụng TDD cho thiết kế API). Bạn cũng được khuyến khích thêm nhiều thử nghiệm và nghĩ về các đầu vào / sử dụng hoang dã mà thử nghiệm có thể nhận được. Tôi thấy nó hữu ích khi viết thư viện hoặc API trong đó nếu bạn thay đổi thứ gì đó bạn phải biết bạn đã phá vỡ thứ gì đó. Trong hầu hết các phần mềm hàng ngày tôi không bận tâm vì tại sao tôi cần một trường hợp thử nghiệm cho người dùng nhấn nút hoặc nếu tôi muốn chấp nhận danh sách CSV hoặc danh sách với một mục nhập trên mỗi dòng ... Điều đó không thực sự quan trọng tôi cho phép để thay đổi nó do đó tôi không nên / không thể sử dụng TDD.

Phần mềm là hữu cơ, khi kỹ thuật kết cấu là bê tông.

Khi bạn xây dựng cây cầu của mình, nó sẽ vẫn là một cây cầu và không chắc là nó sẽ phát triển thành một thứ khác trong một khoảng thời gian ngắn. Những cải tiến sẽ được thực hiện trong nhiều tháng và nhiều năm, nhưng không phải là giờ và ngày như trong phần mềm.

Khi bạn kiểm tra độc lập, thông thường có hai loại khung bạn có thể sử dụng. Khung hạn chế và không ràng buộc. Các khung không giới hạn (trong .NET) cho phép bạn kiểm tra và thay thế mọi thứ, bất kể các sửa đổi truy cập. Tức là bạn có thể sơ khai và chế nhạo các thành phần riêng tư và được bảo vệ.

Hầu hết các dự án mà tôi đã thấy sử dụng các khung bị ràng buộc (RhinoMocks, NSubstolarship, Moq). Khi bạn kiểm tra với các khung này, bạn phải thiết kế ứng dụng của mình theo cách mà bạn có thể tiêm và thay thế các phụ thuộc trong thời gian chạy. Điều này ngụ ý rằng bạn phải có một thiết kế lỏng lẻo. Thiết kế ghép lỏng lẻo (khi được thực hiện đúng) ngụ ý phân tách mối quan tâm tốt hơn, đó là một điều tốt.

Tóm lại, tôi tin rằng suy nghĩ đằng sau điều này, là nếu thiết kế của bạn có thể kiểm tra được, do đó, nó được ghép lỏng lẻo và nó có một mối quan tâm tốt.

Bên cạnh đó, tôi đã thấy các ứng dụng thực sự có thể kiểm tra được, nhưng được viết kém từ quan điểm thiết kế hướng đối tượng.

Tại sao TDD hoạt động?

Nó không.

Làm rõ: kiểm tra tự động tốt hơn so với không kiểm tra. Tuy nhiên, cá nhân tôi nghĩ rằng hầu hết các bài kiểm tra đơn vị là lãng phí vì chúng thường là tautological (nghĩa là những điều hiển nhiên từ mã thực tế được kiểm tra) và không thể dễ dàng chứng minh rằng chúng nhất quán, không dư thừa và bao gồm tất cả các trường hợp biên (thường xảy ra lỗi ).

Và quan trọng nhất: Thiết kế phần mềm tốt không rơi ra khỏi các thử nghiệm một cách kỳ diệu vì nó được quảng cáo bởi nhiều nhà truyền giáo TDD nhanh nhẹn. Mọi người tuyên bố khác, vui lòng cung cấp các liên kết đến nghiên cứu khoa học được đánh giá ngang hàng, điều này chứng minh điều này, hoặc ít nhất là tham khảo một số dự án nguồn mở nơi mà lợi ích của TDD có thể được nghiên cứu bằng cách thay đổi lịch sử mã của nó.