Các nhà phát triển giỏi biết họ nên kiểm tra mã của họ. Tuy nhiên, quá thường xuyên, các bài kiểm tra bị bỏ qua, chạy nhanh hoặc không bao giờ bắt đầu. Có một số bẫy thực sự phổ biến mà tôi từng thấy mọi người rơi vào và chúng sẽ giết chết động lực của bạn để kiểm tra mọi lúc.
1. Tôi có nên sử dụng RSpec không? Quả dưa chuột? Capybara? Nhỏ nhất?
Khi bạn bắt đầu một dự án mới, đó là cách quá dễ dàng để dành nhiều thời gian cố gắng chọn những công cụ tốt nhất. Kiểu trì hoãn này che giấu sự thật rằng bạn không biết bắt đầu từ đâu và cho đến khi bạn chọn công cụ của mình, bạn có thể cảm thấy hiệu quả mà không thực sự đang hiệu quả.
Thay vào đó, chỉ cần chọn ngăn xếp mà bạn biết rõ nhất. Nếu bạn chưa có kinh nghiệm với bất kỳ ngăn xếp thử nghiệm cụ thể nào, hãy sử dụng mặc định – bắt đầu với những gì Rails cung cấp cho bạn. Bạn luôn có thể bổ sung thêm sau. Không có gì sai khi thử các công cụ mới, nhưng đó là một nhiều ý tưởng tốt hơn là giới thiệu chúng theo thời gian, khi bạn hiểu rõ hơn về dự án và quy trình làm việc của mình.
2. Tôi có bắt đầu với các bài kiểm tra đơn vị không? Các bài kiểm tra chức năng? Kiểm tra tích hợp?
Khi bạn bắt đầu một dự án, bạn nên có ý tưởng về những tính năng hoặc màn hình nào nên được xây dựng trước. Đây là một nơi tuyệt vời để bắt đầu! Chọn điều đầu tiên khỏi danh sách tính năng của bạn và viết một bài kiểm tra tích hợp thất bại cho nó. Điều này sẽ cho bạn biết bạn đang thiếu loại bộ điều khiển và tuyến nào, có nghĩa là bạn cần phải viết một số thử nghiệm chức năng không thành công. Bộ điều khiển cần dữ liệu và logic để thực hiện công việc của họ, vì vậy, tiếp theo bạn sẽ viết các bài kiểm tra đơn vị và mô hình của mình. Sau đó, khi bạn vượt qua các bài kiểm tra đơn vị, các bài kiểm tra chức năng sẽ vượt qua và bài kiểm tra tích hợp cũng vậy. Bây giờ bạn có thể chuyển sang tính năng tiếp theo.
Nếu bạn có một quy trình thử nghiệm luôn xác định bước tiếp theo, thì việc duy trì động lực sẽ dễ dàng hơn rất nhiều. Nếu bạn không phải đưa ra quyết định, sẽ có ít cơ hội để sự trì hoãn xuất hiện.
3. Tôi không biết cách kiểm tra mã mạng, tiện ích dòng lệnh hoặc tác vụ cào này!
Điều dễ dàng nhất để làm ở đây là di chuyển càng nhiều mã ra khỏi tệp hoặc lớp khó kiểm tra và sang một đối tượng mới dễ kiểm tra. Bằng cách đó, thứ khó kiểm tra chỉ tạo và chuyển các tham số cho đối tượng mới của bạn.
Tất nhiên, bạn vẫn vẫn có điều gốc khó kiểm tra. Nhưng có lẽ bây giờ chỉ là một vài dòng mã và việc khai báo hoặc giả mạo nó sẽ dễ dàng hơn.
4. “Dự án sắp hoàn thành, bây giờ tôi chỉ cần viết các bài kiểm tra cho nó!”
Mọi nhà phát triển tôi đã gặp đều khao khát mã vận chuyển. Nếu các bài kiểm tra là điều cuối cùng cần làm trước khi bạn có thể giao hàng, bạn sẽ viết số lượng bài kiểm tra tối thiểu mà bạn cần để cảm thấy tự tin rằng mã hoạt động, có thể là như vậy. Nếu bạn có thói quen này, bạn sẽ bắt đầu thấy các bài kiểm tra là khó chịu thay vì hữu ích và sẽ khó hơn rất nhiều để thúc đẩy bản thân viết chúng.
Một trong những điều yêu thích của tôi về TDD là nó kết hợp thử nghiệm với thiết kế và mã hóa, có nghĩa là bạn bắt đầu thấy thử nghiệm as viết mã, điều này làm cho nó thú vị hơn nhiều (và bạn nhận được lợi ích của việc thực hiện các thử nghiệm rất nhiều sớm hơn).
5. Nếu tôi làm sai thì sao?
Cộng đồng Ruby được biết đến với việc thực sự thúc đẩy chất lượng mã, kiểm thử đơn vị và các nguyên tắc thiết kế hướng đối tượng. Đây là một điều tuyệt vời! Thật không may, điều đó có nghĩa là bạn thực sự cảm thấy áp lực rất lớn trong việc gửi mã hoàn hảo với phạm vi kiểm tra 100% trong lần thử đầu tiên của bạn.
Điều này làm cho việc bắt đầu một dự án thực sự khó khăn, đặc biệt là mã nguồn mở, nơi bạn biết người khác sẽ nhìn thấy mã. Mọi người sẽ nói gì nếu họ thấy rằng nó không tuân theo tất cả các nguyên tắc SOLID? Nhưng có một số điều tôi học được đã giúp tôi đối phó với áp lực này:
- Mọi nhà phát triển giỏi viết mã mà họ cảm thấy bối rối sau đó.
- Mã tốt được vận chuyển sẽ tốt hơn vô cùng so với mã hoàn hảo không có.
- Một số người chỉ là những kẻ lừa đảo và sẽ chế giễu mã của bạn. Điều này thực sự tệ. Nó đã hủy hoại cả tuần của tôi. Nhưng các nhà phát triển giỏi muốn trợ giúp bạn thay vì chỉ trích bạn. Và tôi dám cá rằng nếu bạn cho người hùng lập trình của bạn xem đoạn mã đó, họ sẽ không chế giễu nó đâu - họ sẽ giúp bạn làm cho nó tốt hơn.
Bạn còn nhận thấy điều gì khác?
Bạn đã rơi vào bẫy nào trong số những cái bẫy này? Điều gì đã giúp bạn vượt lên chính mình? Và có bất kỳ điều gì tôi chưa đề cập đến mà bạn đã nhận thấy không?
Nếu bạn nhận ra mình trong bất kỳ cái bẫy nào trong số những cái bẫy này, bạn sẽ làm gì để thoát ra?