Tôi đã viết rất nhiều về TDD. Vì vậy, không có gì ngạc nhiên khi tôi xuất bản bài viết cuối cùng của mình vào gần đúng phút David Heinemeier Hansson đã đề cập đến TDD trong bài phát biểu RailsConf của mình, tôi có một số câu hỏi:
Bạn có đồng ý với ý kiến của DHH về TDD không? Bạn vẫn đề xuất TDD? Nếu không, tôi nên làm gì để thay thế?
DHH Đã nói gì
Nếu bạn bỏ lỡ bài phát biểu quan trọng, bài luận của DHH đã nắm bắt được ý chính của nó:
Có lẽ cần phải sử dụng thử nghiệm đầu tiên như một bộ nhớ phản trực giác để phá vỡ sự thiếu sót đáng tiếc của ngành thử nghiệm hồi quy, tự động. Có thể đó là một câu chuyện ngụ ngôn không nhằm mục đích mô tả theo nghĩa đen về hoạt động hàng ngày của việc viết phần mềm. Nhưng bất kể nó bắt đầu như thế nào, nó đã sớm bị hỏng. Được sử dụng như một cái búa để đánh gục những người không tin tưởng, tuyên bố họ không chuyên nghiệp và không thích hợp để viết phần mềm. Thử nghiệm quỳ tím.
Đầy đủ. Không còn nữa. Tên tôi là David, và tôi không viết phần mềm trước tiên. Tôi từ chối xin lỗi vì điều đó nữa, ít giấu giếm nó hơn. Tôi rất biết ơn vì những gì TDD đã làm để mở mang tầm nhìn cho thử nghiệm hồi quy tự động, nhưng tôi đã chuyển từ giáo điều thiết kế từ lâu rồi.
…
Vâng, thử nghiệm đầu tiên là chết đối với tôi. Nhưng thay vì nhảy múa trên ngôi mộ của nó, tôi muốn tôn vinh những đóng góp của nó hơn là nán lại những vết tích. Nó đánh dấu một giai đoạn quan trọng trong lịch sử của chúng ta, nhưng đã đến lúc phải tiếp tục.
Toàn bộ điều đáng đọc, nhưng tôi đã khám phá ra một số điểm chính:
- TDD là một thủ thuật để khuyến khích kiểm tra hồi quy tự động
- Cách hùng biện đầu tiên trong bài kiểm tra tức giận dẫn đến nỗi buồn và tuyệt vọng
- TDD dẫn đến các mạng đối tượng quá phức tạp và chuyển hướng
- Bạn nên thích kiểm tra hệ thống riêng biệt hơn kiểm tra đơn vị
- Nhưng bạn không nên biến sở thích đó thành một tôn giáo khác
- Vì những lý do đó, thử nghiệm trước không phải là một phương pháp thiết kế mà bạn nên sử dụng nữa.
Trong bài luận, hầu hết các điểm này gắn liền với nhau. Chúng có ý nghĩa riêng của chúng, nhưng không hòa quyện vào nhau như chúng được tạo ra.
Nếu bạn không tách chúng ra, tranh luận một điểm sẽ giả định những điểm khác mà bạn có thể không thực sự đồng ý. Khi bạn kết hợp điều đó với sự phẫn nộ trên twitter và giới hạn 140 ký tự, bạn sẽ gặp phải sự nhầm lẫn, rơm rạ và súng lửa.
Thay vào đó, tôi sẽ nói riêng về một vài điểm trong số này.
TDD dẫn đến các mạng đối tượng quá phức tạp và chuyển hướng
Gần đây, tôi thấy cộng đồng thử nghiệm Ruby ưa thích “mạng phức tạp của các đối tượng và sự chuyển hướng”. Tôi nghĩ đây là một điều tồi tệ. (Đó là một trong những lý do ban đầu tôi chạy từ Java!) Nhưng tôi không đồng ý rằng TDD gây ra điều đó.
Tôi đã TDD gần một thập kỷ và tôi không tách các thử nghiệm của mình khỏi cơ sở dữ liệu. Các thử nghiệm chức năng cấp bộ điều khiển và một bộ thử nghiệm tích hợp mạnh mẽ cũng là những phần có giá trị trong tổng bộ thử nghiệm của tôi, bất kể chúng chạy chậm đến mức nào.
Cách ly các thử nghiệm của bạn khỏi hệ thống chỉ là tối ưu hóa. Và YAGNI nói rằng nó có lẽ chưa phải là tất cả những điều quan trọng. Bên cạnh đó, tôi muốn tăng tốc độ toàn diện từ việc tải trước ứng dụng và SSD thay vì cố gắng tối ưu hóa từng thử nghiệm riêng lẻ.
Điều đó nói lên rằng, TDD vẫn có ảnh hưởng đến thiết kế hệ thống của bạn.
TDD phát triển mã của bạn một cách tự nhiên. Đây có thể là một điều tuyệt vời! Nhưng đôi khi, một nhà phát triển phần mềm lành nghề có thể viết mã trông đẹp hơn TDD đã thiết kế. Nó có thể được kết hợp chặt chẽ hơn với mã khác, nó có thể không tuân theo tất cả các quy tắc OOD, nhưng rõ ràng, dễ hiểu và đơn giản. (DHH Ping Pong có một số ví dụ điển hình).
TDD cũng có thể khóa bạn vào một thiết kế API đối tượng trước khi bạn thực sự biết mình đang xây dựng cái gì. Điều này khiến việc thay đổi API sau này trở nên khó khăn hơn. Và xung đột đó có thể khiến bạn quyết định chọn một thiết kế tồi hơn.
Test-first không phải là một phương pháp thiết kế mà bạn nên sử dụng nữa
TDD là một công cụ tuyệt vời để tạo mã linh hoạt, đã được kiểm tra tốt. Vì vậy, tôi hoàn toàn không đồng ý với điểm này. Tôi đã nói về nhiều lợi ích của TDD trong một bài viết trước:
- Bạn sẽ thấy mình có một mô hình đối tượng được thử nghiệm, linh hoạt hơn.
- Theo định nghĩa, hệ thống của bạn có thể kiểm tra được, giúp cho việc viết các bài kiểm tra trong tương lai ít tốn kém hơn.
- Bạn phân bổ chi phí thử nghiệm của mình trong suốt quá trình phát triển, làm cho các ước tính của bạn chính xác hơn.
- Nó giúp bạn luôn trôi chảy, bởi vì bạn không bao giờ phải quyết định phải làm gì tiếp theo.
Bên cạnh những lợi ích đó, nó giúp bạn luyện tập thử nghiệm. Bởi vì bạn luôn viết bài kiểm tra của mình trước, bạn sẽ kiểm tra rất nhiều nhiều hơn nếu bạn đã cố gắng kiểm tra sau khi thực tế . Bạn sẽ biết ngay liệu các bài kiểm tra của mình có thực sự chính xác hay không (vì chúng sẽ thất bại trước). Ngoài ra, bạn không có lý do gì để bỏ qua các bài kiểm tra “một lần này”.
Lời nói đầu tiên trong bài kiểm tra tức giận dẫn đến buồn bã và tuyệt vọng
Hoàn toàn đồng ý 100%. Có, tôi đăng lại bài này. Nhưng nếu ai đó không TDDing vì họ không biết về những lợi ích, hoặc họ chưa hoàn toàn học được cách thực hiện, hoặc họ cảm thấy không thoải mái với nó, cách tiếp cận đúng không làm họ xấu hổ, nó là để giúp đỡ chúng. Nếu TDD hữu ích cho bạn, hãy cho họ thấy nó giúp bạn như thế nào. Nếu họ quan tâm, hãy giúp họ bắt đầu.
Nếu họ không TDDing vì họ thích cách mã hiển thị mà không có TDD, hãy để họ.
Khi bạn xây dựng kiến thức chuyên môn, bạn sẽ phát triển trực giác của riêng mình, sở thích của riêng bạn và các kỹ thuật ưa thích của riêng bạn để phát triển phần mềm. Và không có lập luận nào trên internet sẽ dạy một chuyên gia bỏ qua những điều đó.
Vì vậy, nếu bạn định chỉ trích ai đó không tuân theo ý tưởng của bạn về các phương pháp hay nhất, bạn sẽ làm tổn hại khả năng học hỏi của họ hoặc hét vào hư vô. Điều đó là lãng phí thời gian trong trường hợp tốt nhất và làm tổn hại đến chính nghĩa của bạn trong trường hợp xấu nhất.
Vậy bạn có nên giữ TDDing không?
Vâng! Tôi hoàn toàn khuyên bạn nên học và thực hành nó.
Tôi ghi công TDD vì đã dạy tôi cách kiểm tra, và tôi vẫn nhận được những lợi ích to lớn khi tôi TDD. Nó không hoàn hảo, nhưng không có một kỹ thuật nào là chìa khóa để tạo ra mã tốt hơn một cách kỳ diệu.
Thay vào đó, bạn phải tiếp tục học các mẫu, kỹ thuật và công cụ mới. Thực hành áp dụng chúng cho đến khi bạn có thể sử dụng đúng mẫu vào đúng nơi vì nó cảm thấy phù hợp .
Khi bạn tìm hiểu, hãy dành một chút thời gian để sửa đổi, cấu trúc lại và thử nghiệm với mã của bạn. Nhìn vào mã cũ và mã mới của bạn. Nhờ người có kinh nghiệm hơn bạn đánh giá. Bạn đã làm cho nó tốt hơn? Đó là cách bạn phát triển.