Bạn muốn test-drive một đoạn code, nhưng bị mắc kẹt. Có thể bạn không hoàn toàn chắc interface của object nên trông như thế nào. Có thể bạn bị phân tâm bởi một ngày hè nắng đẹp. Bạn có thể không chắc có thể test điều bạn đang nghĩ xây dựng. Hoặc bạn đang trì hoãn, vì đơn giản không muốn viết test lúc này. Làm sao để nhận được lợi ích của TDD khi bạn không muốn làm TDD?
Nghiệm thu, hoặc xây dựng một cái để ném đi
"Khi một khái niệm hệ thống mới hoặc công nghệ mới được sử dụng, người ta phải xây dựng một hệ thống để ném đi, vì ngay cả kế hoạch tốt nhất cũng không đủ thánh thông để làm đúng ngay lần đầu. Do đó hãy tính toán việc ném đi một cái; bạn sẽ làm vậy de bất chấp." – Fred Brooks
Đôi khi, khi bắt đầu một tính năng mới, tôi cảm thấy tê liệt khi nghĩ đến việc viết test đầu tiên. Có quá nhiều quyết định phải đưa ra về interface API nên trông như thế nào, pattern và practice nào phù hợp nhất, và mọi thứ nên kết hợp như thế nào.
Tôi có vài cách để bắt đầu khi mắc kẹt như vậy. Xây dựng prototype là một cách khác.
Khi bạn viết prototype, hãy coi nó như một bản phác thảo. Động não và thử nghiệm. Đừng lo về test hay TDD lúc này. Thay vào đó, hãy khám phá những quyết định bạn khó khăn, bằng code. Thử một vài pattern, xem pattern nào phù hợp với tính năng bạn đang thiết kế. Tìm ra những phần rung lắc của app, những gì cần suy nghĩ thêm, và những gì bạn lo lắng vô cớ.
Sau đó, ném nó đi và xây dựng lại. Lần này, dùng TDD và kiến thức mới về cách tốt nhất để xây dựng tính năng.
Bạn biết cảm giác khi bạn vô tình chạy git checkout -f sau khi viết gì đó, và cảm thấy như bị đá vào bụng? Nhưng rồi bạn nghĩ, cái này phải xây dựng, nên làm lại thôi, và kết quả tốt hơn lần đầu rất nhiều? Việc rebuild prototype cũng vậy. Bây giờ bạn đã có ý tưởng vững chắc về cách tính năng có thể trông như thế nào, TDD tính năng đó sẽ dễ dàng hơn nhiều.
Reverse TDD
Bạn có bao giờ gặp tình huống biết cách xây dựng thứ gì đó, nhưng không biết cách viết test cho nó trước? Hoặc có thể chỉ là thay đổi một dòng trong một method, nhưng có thể cần điều chỉnh, nên bạn không muốn khóa nó lại bằng test trước khi biết thay đổi sẽ trông như thế nào?
Có một quy trình đơn giản giúp ích rất nhiều cho những tình huống này:
- Viết code, không có test.
- Viết test cho code đó. Đảm bảo nó pass.
- Comment out code bạn vừa viết, hoặc revert file bạn đã thay đổi.
- Chạy test lại. Đảm bảo nó fail.
- Viết code lại. Chạy test. Đảm bảo chúng pass.
- Refactor code, tận dụng test mới.
Tôi coi đây là Reverse TDD hoặc Green-Red-Green-Refactor. Bạn sẽ không có phần "test-driven design" của TDD, nhưng bạn vẫn thấy test fail khi code bị hỏng. Điều đó quan trọng, vì bạn không thể tin tưởng test không fail ít nhất một lần.
Reverse TDD thường hiệu quả nhất với những thay đổi nhỏ không cần nhiều thiết kế. Nghĩ đến bugfix, hoặc thay đổi cục bộ trong một dòng, method, hoặc class. Nhưng tôi dùng kỹ thuật này rất nhiều, đặc biệt cho những thay đổi nhỏ mà tôi vẫn đang "chơi" với nó.
Trò chơi Pairing (Cặp đôi)
Trò chơi Pairing là cách tuyệt vời để thoát khỏi quy trình Red-Green-Refactor khi bạn có một lập trình viên khác cùng làm việc. Nó hoạt động như sau:
- Tìm một partner.
- Bạn viết một test sẽ fail.
- Partner của bạn cố gắng fix test đó với code đơn giản nhất có thể.
- Bạn viết test khác sẽ fail trên code đó.
- Partner viết code để pass test đó.
- Lặp lại…
- Khi nào test pass, bạn có thể chọn refactor code thay vì viết test.
- Sau khi refactor, đổi vai tester và coder.
Tôi sẽ chia sẻ bí mật: chơi trò chơi Pairing trên một máy tính điểm bowling là cách tôi học TDD ban đầu. Nó giúp bạn thực hành viết code đơn giản dựa trên test fail, và viết những test đó. Cả hai dev đều học nhiều về coding style và kỹ thuật yêu thích của nhau. Bạn sẽ nhanh chóng đạt trạng thái flow, nghĩa là bạn sẽ cảm thấy tuyệt vời khi kết thúc.
Bạn có thể không sản xuất code nhanh bằng, nhưng rất vui, và trải nghiệm học tập tuyệt vời.
Giữ tinh thần vui vẻ và thử nghiệm
TDD không nên là giáo điều. Có những cách bạn có thể "chơi" với các khái niệm cốt lõi của TDD có thể dẫn bạn đến những nơi thú vị. Và bạn có thể kết thúc với code thậm chí tốt hơn.
Vì vậy hãy thử nghiệm. Thử các cách tiếp cận mới để viết code và TDD. Xem chúng khiến bạn cảm thấy như thế nào, và bạn kết thúc với loại code nào. Và hãy liên tục khám phá lại niềm vui và sự flow trong công việc hàng ngày.