Dev giỏi biết họ nên test code. Quá thường xuyên, tuy nhiên, test bị bỏ qua, vội vã, hoặc không bao giờ bắt đầu. Có những bẫy thực sự phổ biến tôi thấy người ta rơi vào, và chúng giết động lực test mỗi lần.
1. Nên dùng RSpec? Cucumber? Capybara? Minitest?
Khi bắt đầu project mới, quá dễ dàng mất nhiều thời gian cố chọn tool tốt nhất. Loại trì hoãn này che giấu thực tế bạn không biết bắt đầu đâu, và cho đến khi chọn tool, bạn có thể cảm thấy productive mà không thực sự productive.
Thay vào đó, chỉ chọn stack bạn biết tốt nhất. Nếu bạn không có kinh nghiệm với test stack nào, lấy default–bắt đầu với thứ Rails cho. Bạn luôn có thể thêm sau. Không có gì sai khi thử tool mới, nhưng ý tưởng tốt hơn nhiều là giới thiệu chúng theo thời gian, khi bạn hiểu project và workflow tốt hơn.
2. Nên bắt đầu với unit test? Functional test? Integration test?
Khi bắt đầu project, bạn nên có ý tưởng feature hoặc màn hình nào nên build trước. Đây là nơi tuyệt vời để bắt đầu! Lấy thứ đầu tiên khỏi feature list và viết failing integration test cho nó. Điều này sẽ nói cho bạn biết loại controller và route nào thiếu, nghĩa là bạn cần viết failing functional test. Controller cần data và logic để làm việc, nên bạn viết unit test và model tiếp. Khi unit test pass, functional test sẽ pass, và integration test cũng pass. Bây giờ bạn có thể chuyển sang feature tiếp theo.
Nếu bạn có quy trình testing luôn có bước tiếp theo xác định, dễ dàng giữ động lực hơn. Nếu bạn không phải quyết định, có ít cơ hội hơn cho trì hoãn lén lút.
3. Tôi không biết cách test network code, command line utility, hoặc rake task!
Điều dễ nhất ở đây là di chuyển càng nhiều code ra khỏi file/class khó test vào object mới dễ test. Cách đó, thứ khó test chỉ tạo và truyền tham số cho object mới.
Tất nhiên, bạn vẫn có thứ gốc khó test. Nhưng nó có thể chỉ vài dòng code, và nên dễ stub hoặc fake hơn.
4. "Dự án gần xong, giờ chỉ còn viết test cho nó!"
Mọi dev tôi gặp khao khát ship code. Nếu test là việc cuối cùng trước khi ship, bạn sẽ viết số test tối thiểu để cảm thấy khá tự tin code chạy, có lẽ. Nếu bạn rơi vào thói quen này, bạn sẽ bắt đầu thấy test như phiền toái thay vì hữu ích, và sẽ khó hơn để tự động lực viết test.
Một điều tôi yêu thích về TDD là nó trộn testing với design và coding, nghĩa là bạn bắt đầu thấy testing là coding, làm cho nó vui hơn nhiều (và bạn có lợi ích test rất nhiều sớm hơn).
5. Nếu tôi làm sai thì sao?
Cộng đồng Ruby nổi tiếng với việc đẩy mạnh code quality, unit testing, và nguyên tắc OOP. Điều này tuyệt vời! Thật không may, nó có nghĩa là rất thường thấy áp lực khổng lồ phải ship code hoàn hảo với 100% coverage lần đầu.
Điều này làm khó bắt đầu project, đặc biệt open source, nơi bạn biết người khác sẽ xem code. Mọi người sẽ nói gì nếu thấy nó không tuân theo tất cả SOLID principles? Nhưng có vài điều tôi học được giúp tôi xử lý áp lực này:
- Mọi dev giỏi viết code họ xấu hổ sau này.
- Code tốt ship được tốt vô tận hơn code hoàn hảo không ship.
- Một số người chỉ là kẻ xấu tính và sẽ chê code bạn. Điều này thật tệ. Nó đã phá hoại cả tuần của tôi. Nhưng dev tốt muốn giúp bạn thay vì chê. Và tôi cá cược nếu bạn show code đó cho anh hùng lập trình của bạn, họ sẽ không chê–họ sẽ giúp bạn làm nó tốt hơn.
Bạn đã nhận ra gì khác?
Bạn rơi vào bẫy nào? Điều gì giúp bạn thoát ra? Và có bẫy nào tôi không nhắc mà bạn thấy?
Nếu bạn nhận ra mình trong bẫy nào, bạn sẽ làm gì để thoát ra?