Tính trực giao của kiểm tra đơn vị so với kiểm tra đơn vị

Tôi đang viết bài kiểm tra đơn vị cho một hệ thống lái cho một trò chơi video. Hệ thống có một số hành vi (tránh khu vực này vì lý do A, tránh khu vực này vì lý do B, mỗi khu vực thêm một chút bối cảnh vào bản đồ của khu vực. Một chức năng riêng biệt sau đó phân tích bản đồ và tạo ra một chuyển động mong muốn.

Tôi gặp khó khăn khi quyết định viết bài kiểm tra đơn vị cho các hành vi. Như TDD gợi ý, tôi chỉ quan tâm đến cách các hành vi ảnh hưởng đến chuyển động mong muốn. Chẳng hạn, tránh-vì-lý do-A sẽ dẫn đến việc di chuyển ra khỏi vị trí xấu được đề xuất. Tôi thực sự không quan tâm làm thế nào hoặc tại sao hành vi lại thêm bối cảnh vào bản đồ, chỉ có điều là chuyển động mong muốn ở xa vị trí.

Vì vậy, các thử nghiệm của tôi cho từng hành vi thiết lập hành vi, làm cho nó ghi vào bản đồ, sau đó thực hiện chức năng phân tích bản đồ để thực hiện chuyển động mong muốn. Nếu chuyển động đó thỏa mãn thông số kỹ thuật của tôi thì tôi rất vui.

Tuy nhiên, bây giờ các thử nghiệm của tôi phụ thuộc vào cả hai hành vi hoạt động chính xác và chức năng phân tích cú pháp bản đồ hoạt động chính xác. Nếu chức năng phân tích cú pháp thất bại, thì tôi sẽ nhận được hàng trăm thử nghiệm thất bại thay vì một vài. Nhiều hướng dẫn viết bài kiểm tra cho thấy đây là một ý tưởng tồi.

Tuy nhiên, nếu tôi kiểm tra trực tiếp đầu ra của các hành vi bằng cách chế nhạo bản đồ, thì chắc chắn tôi đang kết nối quá chặt chẽ với việc thực hiện? Nếu tôi có thể có được chuyển động mong muốn tương tự từ bản đồ bằng cách sử dụng một hành vi hơi khác, thì các bài kiểm tra vẫn sẽ vượt qua.

Vì vậy, bây giờ tôi đang chịu đựng sự bất hòa về nhận thức. Cách tốt nhất để cấu trúc các bài kiểm tra này là gì?

Trong thế giới lý tưởng, bạn thực sự sẽ có một bộ các bài kiểm tra đơn vị hoàn toàn trực giao, tất cả đều ở cùng một mức độ trừu tượng.

Trong thế giới thực, bạn thường có các bài kiểm tra trên nhiều cấp độ khác nhau của ứng dụng, do đó, thường thì chức năng thực hiện các bài kiểm tra ở cấp độ cao hơn đã được kiểm tra bằng các bài kiểm tra cấp thấp chuyên dụng. (Nhiều người thích gọi các bài kiểm tra hệ thống con / kiểm tra tích hợp cấp cao hơn như kiểm tra đơn vị; tuy nhiên họ vẫn có thể chạy trên cùng một khung kiểm tra đơn vị, do đó, từ quan điểm kỹ thuật không có nhiều khác biệt.)

Tôi không nghĩ rằng đây là một điều xấu. Vấn đề là phải kiểm tra mã của bạn theo cách tốt nhất phù hợp với dự án và tình huống của bạn, không tuân thủ "cách lý tưởng".

Loại thử nghiệm này là lý do tại sao giả được phát minh. Ý tưởng chính: Bạn viết một bản giả cho đối tượng của bạn (bản đồ, hành vi, nhân vật, ...), sau đó viết các bài kiểm tra bằng cách sử dụng bản giả đó thay vì đối tượng thực tế. Mọi người đôi khi gọi các cuống giả, và tôi tin rằng có những từ khác cho cả hai.

Trong trường hợp của bạn, bạn sẽ viết một bản giả cho bản đồ bất cứ khi nào bạn cần kiểm tra các hành vi và các bản giả khác cho các hành vi bất cứ khi nào bạn muốn kiểm tra bản đồ. Giả của bạn lý tưởng sẽ đơn giản hơn nhiều so với các hành vi thực tế bạn đang chế giễu, chỉ kết hợp các phương pháp hoặc các biến bạn thực sự cần cho bài kiểm tra đó. Bạn có thể phải viết một bản giả khác nhau cho mỗi bài kiểm tra, hoặc bạn có thể sử dụng lại một số bản giả. Bất kể, chúng phải phù hợp với thử nghiệm và không nên cố gắng giống với hành vi thực tế nhất có thể.

Nếu bạn bao gồm một số ví dụ về bản đồ hoặc hành vi, có lẽ ai đó có thể cung cấp các ví dụ về các giả định bạn có thể viết. Không phải tôi, vì tôi chưa bao giờ lập trình một trò chơi video tiên tiến hơn Pông, và thậm chí sau đó tôi đang theo dõi một cuốn sách, nhưng có lẽ ai đó thành thạo trong cả thử nghiệm đơn vị và phát triển trò chơi.

Tôi nghĩ bạn cố gắng kiểm tra những thứ ở cấp độ cao hơn nhiều so với một đơn vị.

Hầu hết các bài kiểm tra hành vi sẽ yêu cầu một số thông minh đằng sau nó, để cho biết nếu nó hành xử đúng. Điều này không thể dễ dàng thực hiện bằng cách sử dụng thử nghiệm tự động.