(Tôi ở Chicago tham dự RailsConf tuần này. Nếu bạn thấy tôi xung quanh, hãy nói xin chào! Tôi rất muốn gặp bạn. Tôi là người lớn tuổi hơn trong hình ở thanh bên.)
Một độc giả đã hỏi một câu hỏi tuyệt vời về thử nghiệm trong nhận xét về một trong những bài viết của tôi:
Tôi biết tôi cũng cần phải di chuyển “bánh đà TDD”, nhưng TDD rất xa lạ đối với tôi. Bạn có bất kỳ khuyến nghị nào về cách tốt nhất để bắt đầu với RSpec hay đó chỉ là một kiểu “vào đó và lấy đi”?
Vì vậy, tôi đã trả lời nó:
Nếu bạn chưa giải quyết được vấn đề này hay vấn đề khác, bạn thực sự có thể thấy điều nhỏ nhất là dễ dàng hơn để bắt đầu. Đó là ‘phương pháp và lớp học’ nhiều hơn một chút, vì vậy bạn có thể hoàn toàn tập trung vào việc học và thực hành TDD mà không cần phải học một cú pháp mới.
Rails có một hướng dẫn khá tốt về thuật ngữ thử nghiệm, các xác nhận và cách chạy các thử nghiệm nói chung trong Rails.
Cách tốt nhất để học TDD là luyện tập. Đây là các bước bạn nên làm theo:
- Viết một bài kiểm tra giả định rằng mã bạn cần đã ở đó.
- Chạy các bài kiểm tra, đảm bảo rằng bài kiểm tra mới của bạn không thành công
- Viết đoạn mã đơn giản nhất sẽ vượt qua bài kiểm tra. Đừng quá trừu tượng hoặc tái cấu trúc ở đây.
- Chạy các bài kiểm tra, đảm bảo bài kiểm tra mới của bạn vượt qua
- Cấu trúc lại mã của bạn để loại bỏ sự trùng lặp (hoặc làm cho mã biểu cảm hơn).
- Chạy lại các bài kiểm tra (để đảm bảo chúng vẫn vượt qua).
- Quay lại bước 1.
Trong khi tập TDD, bạn nên liên tục tự hỏi:Tôi đang ở bước nào? Tôi đã bỏ qua một bước? Bước nào tiếp theo? (Bạn phải luôn thực hiện một trong các bước này.) Điều này sẽ giúp bạn đi đúng hướng, điều này thực sự quan trọng trong khi bạn đang học một cái gì đó mới. “Thực hành có tác dụng lâu dài”, vì vậy bạn không muốn thực hành sai!
Nhưng cũng có thể, hãy cho phép bản thân được làm rối tung lên . Bạn đang học, điều đó hoàn toàn ổn! Việc này sẽ dễ dàng hơn rất nhiều khi bạn làm việc đó thường xuyên hơn.
Eric Steele, người cũng đang viết một cuốn sách về thử nghiệm, đã đưa ra một điểm chính mà tôi đã bỏ qua:
Phần TDD bị bỏ lại là số lượng lập kế hoạch xảy ra trước bước 1.
Kiểm tra là nơi các yêu cầu của ứng dụng đáp ứng việc triển khai theo kế hoạch của bạn. Phát triển theo hướng thử nghiệm phụ thuộc rất nhiều vào việc biết ứng dụng phải làm gì và giả định rằng bạn có ý tưởng về cách thực hiện.
Khi chúng tôi lần đầu tiên bắt đầu xây dựng với Rails, chúng tôi không biết nhiều điều. Chúng tôi dành nhiều thời gian để viết mã thử nghiệm cho đến khi nhận được kết quả tương tự như những gì chúng tôi đang tìm kiếm. Bạn làm điều này ít hơn và ít hơn khi bạn học nhiều hơn. Tôi nghĩ đây là lý do tại sao TDD bắt đầu với việc "viết một bài kiểm tra" chứ không phải "tìm ra những gì bạn đang xây dựng". Vào thời điểm bạn đang kiểm tra, bạn đã có rất nhiều kinh nghiệm.
Tôi sẽ thêm các bước này trước khi "Viết bài kiểm tra":
- Suy nghĩ, xác minh và loại bỏ các yêu cầu. Tránh viết mã bằng mọi giá.
- Lập kế hoạch và thiết kế mã của bạn để đáp ứng các yêu cầu đó.
- Tinker với mã để trả lời bất kỳ câu hỏi nào chưa biết, nhưng hãy đặt mã đó sang một bên.
Lời khuyên của tôi:
- Tập trung vào việc lập kế hoạch hơn là cú pháp
- Thu nhỏ các công cụ của bạn (tôi thấy minitest / fixtures thực sự hữu ích)
- Thực hành, thực hành, thực hành.
Cũng giống như bất cứ điều gì, bắt đầu với TDD cần thực hành và khả năng tự sửa chữa (hoặc nhờ ai đó xung quanh sửa cho bạn). Nếu bạn có thể làm theo một số bước nửa cứng nhắc và lưu ý về vị trí của bạn trong quá trình này, TDD sẽ sớm cảm thấy hoàn toàn tự nhiên đối với bạn.