Tôi viết khá nhiều về TDD. Vì vậy, không ngạc nhiên khi tôi xuất bài viết gần đây gần như chính xác phút David Heinemeier Hansson nhắc đến TDD trong keynote RailsConf, tôi nhận được vài câu hỏi:
Bạn có đồng ý với quan điểm của DHH về TDD? Bạn vẫn khuyến khích TDD? Nếu không, tôi nên làm gì thay thế?
DHH nói gì
Nếu bạn bỏ lỡ keynote, bài essay của DHH nắm bắt tinh thần:
Có lẽ test-first là cần thiết như cái búa phản trực giác để phá vỡ sự thiếu hụt testing tự động, regression của ngành. Có lẽ đó chỉ là một ẩn dụ không từng định là mô tả văn minh cho công việc hàng ngày viết phần mềm. Nhưng bất kể nó bắt đầu như thế nào, nó nhanh chóng bị biến chất. Được dùng như cây gậy đánh người không tin, tuyên bố họ không chuyên nghiệp và không phù hợp viết software. Một bài test kim loại.
Đủ rồi. Không nữa. Tên tôi là David, và tôi không viết software test-first. Tôi từ chối xin lỗi cho điều đó nữa, nhiều hơn là giấu nó. Tôi biết ơn TDD đã mở mắt tôi về automated regression testing, nhưng tôi đã lâu rời xa dogma thiết kế đó.
…
Có, test-first đã chết đối với tôi. Nhưng thay vì nhảy múa trên mồ mộ nó, tôi muốn tôn vinh đóng góp của nó hơn là ám ảnh về bi kịch. Nó đánh dấu một giai đoạn quan trọng trong lịch sử, nhưng đã đến lúc tiến lên.
Cả bài đáng đọc, nhưng tôi tách ra một số điểm chính:
- TDD là mind hack khuyến khích automated regression testing
- Lời lẽ gay gắt test-first dẫn đến buồn bã và tuyệt vọng
- TDD dẫn đến mạng lưới object và indirection quá phức tạp
- Bạn nên ưu tiên isolated system tests hơn unit tests
- 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 đó, test-first không còn là practice thiết kế bạn nên dùng.
Trong essay, hầu hết các điểm được gắn kết. Chúng có ý nghĩa riêng, nhưng không xen lẫn như được trình bày.
Nếu bạn không tách chúng ra, tranh luận một điểm giả định các điểm khác bạn có thể không đồng ý. Kết hợp với sự phẫn nộ Twitter và giới hạn 140 ký tự, bạn có sự nhầm lẫn, scarecrow, và flamewar.
Thay vào đó, tôi sẽ nói về vài điểm riêng biệt.
TDD dẫn đến mạng lưới object và indirection quá phức tạp
Gần đây, tôi thấy xu hướng trong cộng đồng test Ruby ưu tiên "mạng lưới object và indirection phức tạp." Tôi nghĩ đây là điều xấu. (Đây là một lý do tôi từng trốn khỏi Java!) Nhưng tôi không đồng ý TDD gây ra nó.
Tôi TDD gần một thập kỷ, và tôi không isolate test khỏi database. Controller-level functional test và integration test suite vững chắc cũng là phần quý giá của test suite tổng thể, bất kể chúng chạy chậm đến đâu.
Isolate test khỏi hệ thống chỉ là optimization. Và YAGNI nói nó có lẽ không quan trọng lắm. Dù sao, tôi thích boost tốc độ toàn diện từ SSD và app preloading hơn là tối ưu từng test riêng lẻ.
Điều đó nói, TDD vẫn ảnh hưởng đến thiết kế hệ thống.
TDD làm code phát triển organic (tự nhiên). Điều này có thể tuyệt vời! Nhưng đôi khi, dev giỏi có thể viết code đẹp hơn TDD thiết kế. Nó có thể coupled chặt hơn với code khác, có thể không tuân theo mọi quy tắc OOD, nhưng nó rõ ràng, thẳng thắn, và đơn giản. (DHH Ping Pong có ví dụ tốt).
TDD cũng có thể khóa bạn vào thiết kế API object trước khi bạn thực sự biết bạn đang xây dựng gì. Nó làm thay đổi API sau khó hơn. Và ma sát đó có thể khiến bạn chấp nhận thiết kế tồi hơn.
Test-first không còn là practice thiết kế bạn nên dùng
TDD là công cụ tuyệt vời tạo code linh hoạt, well-tested. Vì vậy tôi hoàn toàn không đồng ý điểm này. Tôi đã nói về nhiều lợi ích TDD trong bài trước:
- Bạn sẽ có object model linh hoạt, được test hơn.
- Hệ thống của bạn theo định nghĩa là testable, làm test tương lai rẻ hơn.
- Bạn phân摊 chi phí test qua quy trình dev, làm estimate chính xác hơn.
- Nó giữ bạn trong flow, vì bạn không bao giờ phải quyết định làm gì tiếp theo.
Bên cạnh lợi ích đó, nó giúp bạn luyện tập testing. Vì bạn luôn viết test trước, bạn sẽ test nhiều hơn so với cố gắng test sau. Bạn biết ngay test có đúng không (vì nó fail trước). Thêm vào đó, bạn không có cớ bỏ qua test "lần này thôi".
Lời lẽ gay gắt test-first dẫn đến buồn bã và tuyệt vọng
Hoàn toàn, 100% đồng ý. Có, tôi đăng lại điểm này. Nhưng nếu ai không TDD vì không biết lợi ích, hoặc chưa học cách làm, hoặc cảm thấy khó chịu, cách tiếp cận đúng không phải shaming (xúc phạm), mà là giúp đỡ họ. 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, giúp họ bắt đầu.
Nếu họ không TDD vì thích cách code ra mà không TDD, hãy để họ.
Khi bạn xây dựng chuyên môn, bạn sẽ phát triển trực giác, gu, và kỹ thuật ưa thích riêng. Và không tranh luận internet nào dạy chuyên gia bỏ qua những điều đó.
Vì vậy, nếu bạn định chỉ trích ai không theo best practice của bạn, bạn hoặc làm hại khả năng học của họ, hoặc la hét vào hư không. Đó là lãng phí thời gian ở trường hợp tốt, và hại sự nghiệp bạn ở trường hợp xấu.
Vậy bạn có nên tiếp tục TDD không?
Có! Tôi hoàn toàn khuyên bạn học và practice nó.
Tôi ghi nhận TDD dạy tôi cách test, và tôi vẫn nhận lợi ích lớn khi TDD. Nó không hoàn hảo, nhưng không kỹ thuật nào là chìa khóa phép màu sản xuất code tốt hơn.
Thay vào đó, bạn phải tiếp tục học pattern, kỹ thuật, công cụ mới. Practice áp dụng cho đến khi bạn dùng pattern đúng ở nơi đúng vì nó cảm thấy đúng.
Khi bạn học, hãy dành thời gian modify, refactor, và experiment với code. Nhìn code cũ và code mới. Nhờ người giỏi hơn review. Bạn có làm nó tốt hơn không? Đó là cách bạn lớn.