(Tôi đang ở Chicago cho RailsConf tuần này. Nếu thấy tôi, chào nhé! Tôi là người lớn tuổi hơn trong ảnh ở sidebar.)
Một độc giả hỏi câu hỏi hay về testing trong comment bài viết:
Tôi biết tôi cũng cần quay vòng "TDD flywheel", nhưng TDD rất lạ với tôi. Bạn có khuyến nghị cách bắt đầu với RSpec tốt nhất không, hay chỉ là "nhảy vào hack"?
Vì vậy tôi trả lời:
Nếu bạn chưa quyết định cái nào, bạn thực sự có thể thấy minitest dễ bắt đầu hơn. Nó hơi hơn 'methods và classes', nên bạn có thể tập trung hoàn toàn vào học và practice TDD mà không phải học syntax mới.
Rails có guide khá tốt về thuật ngữ test, assertions, và cách chạy test chung trong Rails.
Cách tốt nhất học TDD là practice. Đây là các bước bạn nên làm theo:
- Viết test giả định code bạn cần đã có sẵn.
- Chạy test, đảm bảo test mới fail
- Viết code đơn giản nhất để pass test. Đừng over-abstract hoặc refactor ở đây.
- Chạy test, đảm bảo test mới pass
- Refactor code để loại bỏ duplication (hoặc làm code expressive hơn).
- Chạy test lại (đảm bảo vẫn pass).
- Quay lại bước 1.
Khi practice TDD, bạn nên liên tục tự hỏi: Tôi ở bước nào? Tôi có bỏ bước nào? Bước nào tiếp theo? (Bạn luôn nên ở một trong các bước này.) Điều này giúp giữ bạn trên đà đúng, rất quan trọng khi học điều mới. "Practice makes permanent", nên bạn không muốn practice sai!
Nhưng cũng, cho phép mình mắc lỗi. Bạn đang học, hoàn toàn OK! Sẽ dễ dàng hơn nhiều khi bạn làm thường xuyên.
Eric Steele, cũng đang viết sách về testing, nêu điểm then chốt tôi bỏ lỡ:
Phần TDD bị bỏ qua là lượng planning xảy ra trước bước 1.
Test là nơi requirement của app gặp implementation bạn dự định. Test driven development phụ thuộc cứng vào việc biết app nên làm gì, và giả định bạn có ý tưởng cách làm.
Khi mới bắt đầu build với Rails, chúng ta không biết nhiều. Chúng ta dành nhiều thời gian viết code thử nghiệm cho đến khi có kết quả giống mong muốn. Bạn làm điều này ít dần khi học nhiều hơn. Tôi nghĩ đó là lý do TDD bắt đầu bằng 'viết test' không phải 'tìm ra bạn đang xây dựng gì'. Khi bạn đến testing, bạn đã có nhiều kinh nghiệm.
Tôi thêm các bước trước 'Viết test':
- Brainstorm, justify, và cull requirements. Tránh code بأي giá.
- Plan và design code đáp ứng requirements đó.
- Thử code để trả lời câu hỏi chưa biết, nhưng để code đó riêng.
Lời khuyên của tôi:
- Tập trung vào planning hơn syntax
- Tối thiểu hóa tool (tôi thấy minitest/fixtures rất giúp)
- Practice, practice, practice.
Giống bất cứ thứ gì, bắt đầu TDD đòi hỏi practice và khả năng tự sửa (hoặc có người sửa cho). Nếu bạn có thể làm theo vài bước nửa cứng nhắc, và giữ tỉnh táo về vị trí bạn trong quy trình, TDD sẽ sớm cảm thấy hoàn toàn tự nhiên.