Mã nào của bạn không được kiểm tra? Đó có phải là mã giải quyết các tình huống phức tạp mà bạn không kiểm soát được không? Chủ đề, lệnh đang chạy, git, mạng hay giao diện người dùng?
Ứng dụng của chúng tôi thú vị nhất khi chúng phức tạp. Chúng cũng nguy hiểm nhất. Và đó là lý do tại sao mã khó kiểm tra chính xác là loại mã cần được kiểm tra tốt. Điều đó không phải lúc nào cũng xảy ra.
Thay vào đó, mỗi khi chạm vào mã đó, bạn chạm nhẹ. Bạn bước cẩn thận. Có thể bạn thực hiện một số thử nghiệm thủ công. Và khi bạn gửi yêu cầu kéo, bạn hy vọng đồng đội của mình không nhận ra rằng những thử nghiệm đó không tồn tại.
Nhưng điều đó sẽ không làm cho mọi thứ tốt hơn. Bạn sẽ gặp cùng một vấn đề, cùng một lỗi, cùng một căng thẳng vào lần sau - và mọi lần sau đó. Cuối cùng thì làm cách nào để bạn có thể thực hiện những bài kiểm tra đầy thử thách đó mà bạn có thể dựa vào?
Thay đổi tư duy của bạn
Điều khó chịu nhất về những bài kiểm tra này? Sẽ mất nhiều thời gian gấp mười lần để viết nó theo ý muốn. Nếu bạn ước tính thời gian mà bài kiểm tra tiết kiệm cho bạn so với thời gian bạn dành để viết bài kiểm tra, thì điều đó có vẻ không đáng.
Nhưng nó không chỉ là về bài kiểm tra này. Đó là về tất cả các bài kiểm tra trong tương lai của bạn .
Hầu hết mã được thử nghiệm tốt nhất mà tôi thấy đều có nhiều hỗ trợ. Nó không chỉ là mã trong test/models . Mã được kiểm tra cực kỳ tốt sẽ có hàng giả, mã giả, có một bộ đồ đạc kiểm tra tốt, nó có các tùy chọn cấu hình dành riêng cho các bài kiểm tra.
Tất cả những gì cần thời gian để viết và tổng hợp lại.
Nhưng một khi bạn có nó, nó cảm thấy thật tuyệt. Bạn có thể nghĩ ra thử nghiệm này đến thử nghiệm khác, cảm thấy thoải mái về mã của mình và tự tin rằng bạn có thể nhanh chóng chuyển đổi sau khi đầu tư bạn đã thực hiện.
Bạn có thể dựa vào về công việc bạn đã làm.
Vì vậy, nó không chỉ là ngăn chặn lỗi trong mã phức tạp. Đó cũng là việc làm cho mã trong tương lai dễ kiểm tra hơn, từng phần một.
Đặt nó làm bài kiểm tra tích hợp (hiện tại)
Tuy nhiên, đôi khi, đó không phải là hiểu giá trị - tôi hiểu. Thay vào đó, tôi chỉ gặp khó khăn vì tôi không thể tìm ra cách viết một bài kiểm tra đơn vị nhỏ, nhanh.
Làm cách nào để bạn biết mình đang chạy các lệnh git phù hợp trong công cụ triển khai của mình mà không thực sự chạy git ? Làm cách nào để đảm bảo rằng bạn đang gửi đến một máy chủ từ xa đúng tiêu đề?
Với đủ thời gian, bạn có thể tạo ra một giả mạo chất lượng để các thử nghiệm của mình dựa vào.
Nhưng khi điều đó dường như là quá nhiều thứ để suy nghĩ, bạn có thể thử làm điều gì đó khác. Chia nhỏ quá trình kiểm tra thành hai bước riêng biệt:“kiểm tra mã” và “viết mô hình.”
Chỉ cần gọi máy chủ đó. Chỉ cần chạy lệnh đó. Tại sao?
- Bắt đầu dễ dàng hơn nhiều. Có thể bạn đang thử nghiệm các lệnh đó theo cách thủ công, phải không? Chạy nó trong một bảng điều khiển hay thử nó trong một trình duyệt? Chỉ cần sao chép nó vào một bài kiểm tra.
- Cuối cùng, khi bạn viết mô hình giả hoặc giả mạo của mình, bạn có thể sử dụng các bài kiểm tra này để đảm bảo mô hình giả của bạn hoạt động. Nếu bạn thấy hành vi trong thế giới thực giống như bạn nhìn thấy từ đồ giả của mình, thì có lẽ hành vi giả mạo của bạn là tốt!
Tuy nhiên, có thể bạn không muốn giữ những thử nghiệm này mãi mãi:
- Họ có tất cả các vấn đề mà kiểm tra tích hợp gặp phải. Chúng có thể chậm. Họ có thể cần kết nối internet trực tiếp. Chúng có thể dễ gãy vì tùy thuộc vào hành vi mà ứng dụng của bạn không thực sự quan tâm.
- Bạn có thể không kiểm tra được một số thứ trong thế giới thực. Ví dụ:làm cách nào để buộc các mã lỗi cụ thể khi bạn không kiểm soát máy chủ ở đầu bên kia?
- Bạn có thể bị chặn bởi một máy chủ mà bạn phụ thuộc vào và điều đó có thể phá vỡ các thử nghiệm của bạn (và ứng dụng của bạn!). Điều này thực sự đã xảy ra với tôi và đó là một vấn đề lớn.
Vì vậy, viết thử nghiệm của bạn dưới dạng thử nghiệm tích hợp trong thế giới thực không phải là giải pháp lâu dài hay thậm chí là lâu dài. Nhưng ngay cả với tất cả những hạn chế đó, nó vẫn hữu ích. Và sau khi bạn thay thế nó, bạn vẫn có thể duy trì kiểm tra tích hợp xung quanh, trong một bộ riêng biệt. Bằng cách đó, bạn luôn có thể kiểm tra mã của tôi so với thực tế, không chỉ là giả định của bạn.
Một số mã chỉ là khó kiểm tra. Phải mất một thời gian để xây dựng cơ sở hạ tầng bạn cần để viết các bài kiểm tra đáng tin cậy một cách nhanh chóng. Và đôi khi, điều đó dường như không đáng.
Nhưng khi bạn ngừng nghĩ về thử nghiệm đơn lẻ đó và nghĩ về giá trị của việc làm cho tất cả các thử nghiệm trong tương lai của bạn trở nên dễ dàng hơn, việc thử nghiệm mã phức tạp sẽ trở nên có động lực hơn rất nhiều. Và một khi bài kiểm tra đầu tiên kết thúc, phần còn lại của chúng dường như trở nên dễ viết hơn một cách kỳ diệu.
Tuy nhiên, đôi khi điều đó vẫn chưa đủ. Điều gì sẽ xảy ra nếu bạn biết cách đảm bảo mã của mình hoạt động trong thế giới thực, nhưng không thể tìm ra cách kiểm tra nó?
Khi điều đó xảy ra, hãy ngừng xem xét bài kiểm tra như một thứ bạn cần giữ trong sáng và biệt lập. Thay vào đó, hãy xem đó là một cách để tự động làm những gì bạn đang làm theo cách thủ công.
Nó không hoàn hảo và bạn nên thay thế nó ngay khi có thể. Nhưng những thử nghiệm đó có thể mang lại cho bạn sự tự tin cần thiết để viết và thay đổi những đoạn mã phức tạp một cách nhanh chóng.