Có phải là một thực hành xấu để tách các bài kiểm tra đơn vị cho một lớp học? [đóng cửa]

Các lớp của tôi thường có tối đa khoảng 5-20 phương thức, điều đó hàm ý rằng lớp có các bài kiểm tra đơn vị có khoảng gấp đôi các phương thức (đếm dataProviders, setUp, ...)

Tôi đã nghĩ cách tách các bài kiểm tra trong 2-3 lớp, bởi vì ngay cả khi tôi cố gắng tuân theo nguyên tắc trách nhiệm duy nhất, tôi thích 2 lớp kiểm tra với 10 phương thức mỗi lớp, hơn một với 20.

Có phải là một thực hành xấu ?? Có tốt không khi có tất cả các bài kiểm tra cho một lớp chỉ trong một, mặc dù lớp kiểm tra phát triển theo chiều dọc?

Để trả lời câu hỏi cụ thể, hoàn toàn có thể việc nhóm các bài kiểm tra thành nhiều lớp là một quyết định tốt, sự kiện khi lớp được kiểm tra được thiết kế tốt.

Mã kiểm tra đơn vị giống như bất kỳ mã nào khác: cần tuân theo các nguyên tắc thiết kế tốt ( DRY , GRASP , KISS , RẮN , YAGNI , v.v.). Bởi vì logic tạo nên mã kiểm tra thường đơn giản hơn logic miền, rất nhiều điểm cụ thể sẽ không xuất hiện nhiều, nhưng hãy ghi nhớ chúng trong khi viết các bài kiểm tra của bạn giống nhau.

Có một vài nguyên tắc xuất hiện trong đầu bạn có thể dễ dàng áp dụng khi nghĩ về câu hỏi của bạn:

Dễ đọc

Lý tưởng nhất, một khi bài kiểm tra được viết, bạn không bao giờ phải nhìn lại nó; nhưng điều tương tự có thể được nói cho bất kỳ mã nào. Thực tế là các yêu cầu thay đổi, vì vậy chúng tôi thấy mình đọc mã nhiều hơn là viết nó. Ngay cả khi cố gắng hết sức, bạn có thể thấy rằng bài kiểm tra bạn đã viết không hoàn toàn xác minh những gì bạn nghĩ nó đã làm, tại thời điểm đó bạn sẽ phải quay lại và tìm ra điều gì sai. Việc tìm ra phương pháp thử nghiệm đó trong một lớp gồm 40-50 phương pháp thử nghiệm sẽ rất khó khăn, chưa kể đến sự phức tạp của việc đặt tên cho các phương thức đó để chúng có thể được phân biệt dễ dàng.

Độ kết dính cao

Mỗi lớp kiểm tra (như bất kỳ lớp nào khác) nên có trọng tâm rõ ràng. Nếu bạn có nhiều trường hợp kiểm thử khác nhau cho một phương thức đã cho của lớp đang kiểm tra, vì khi một bài kiểm tra đã xác minh một điều duy nhất, hãy đặt các phương thức kiểm tra đó vào một lớp riêng và đặt tên cho nó để phản ánh trọng tâm của nó.

Gần như không có tầm quan trọng như thế nào các bài kiểm tra đơn vị của bạn được tổ chức so với việc có chúng ở vị trí đầu tiên.

Một mô-đun hoặc lớp mã doanh nghiệp là thứ bạn phải hiểu như một đơn vị và phát triển hơn nữa. Đó là lý do chính mà chúng tôi cố gắng để làm cho nó mạch lạc, dễ nắm bắt, v.v. Một bộ thử nghiệm chỉ là một tập hợp các trường hợp tất cả phải vượt qua; không có bất kỳ mối quan hệ cụ thể với nhau . Lý tưởng nhất là bạn sẽ không bao giờ phải đối phó với nó nữa; nếu bạn thường làm thêm các bài kiểm tra mà lại không có mối quan hệ cụ thể nào với bất kỳ bài kiểm tra nào khác và chúng không bao giờ được gọi bằng mã máy khách ngoại trừ khung kiểm tra đơn vị.

Do đó, câu hỏi về cách tổ chức các lớp có chứa các bài kiểm tra đơn vị ít quan trọng hơn nhiều so với cách tổ chức các lớp tạo nên ứng dụng của chính bạn. Dù sao thì bạn cũng không phải đối phó với chúng như một cấu trúc vĩ mô được kiến ​​trúc tốt.

Đặt các bài kiểm tra trong một tập tin. Thông thường đối với mỗi tệp lớp tôi sẽ có một tệp thử nghiệm. Thường gắn "Kiểm tra" vào tên tệp.

Ví dụ: nếu có một lớp gọi là "Foo" thì sẽ có một tệp "FooTests" tương ứng. Cách này cho mỗi tệp mã có mối quan hệ 1-1 giữa tệp mã và tệp thử nghiệm.

Điều này cung cấp tính nhất quán và giúp các nhà phát triển dễ dàng xác định vị trí các bài kiểm tra và cập nhật chúng. Các thử nghiệm thường được loại trừ khỏi phân tích / số liệu mã, vì vậy nếu tệp lớn, nó không ảnh hưởng đến chỉ số sức khỏe mã tổng thể, vì vậy tôi không coi đó là hình thức xấu để có tệp thử nghiệm có nhiều mã kiểm tra đơn vị.

Nếu chúng ta nói rằng định nghĩa về thực hành xấu trong phát triển phần mềm là bất cứ điều gì không giúp bạn đối phó và gói gọn sự thay đổi thì tôi sẽ nói rằng không giữ các lớp học và kiểm tra của bạn trong một mối quan hệ là một thực tiễn xấu . Đó là một mùi mã có thể phát sinh vì những điều được đề cập dưới đây.

Rõ ràng có những trường hợp ngoại lệ giống như với bất cứ điều gì nhưng chỉ cần ghi nhớ điều đó khi bạn đang viết bài kiểm tra của mình.

Lớp học của tôi thường có khoảng 5-20 phương thức tối đa.

Nếu bất kỳ lớp nào của bạn có 20 phương thức (hoặc ít hơn một chút) thì loại đó cho tôi thấy rằng lớp học đang làm quá nhiều ở nơi đầu tiên. Đây là nơi kiểm thử đơn vị sẽ gợi ý cho bạn rằng bạn có thể cần phải chia nhỏ lớp của mình thêm một chút và phân phối trách nhiệm trước khi tiến hành kiểm tra.

Đối với việc giữ chúng trong cùng một lớp hay không, tôi khuyên bạn nên cố gắng giữ chúng trong một lớp nếu có thể vì điều đó dễ hiểu hơn - một kết nối dễ dàng nắm bắt sau nhiều thời gian trôi qua. Chỉ từ kinh nghiệm.

Nếu bạn thấy rằng các bài kiểm tra đơn vị là rất lớn ngay cả khi bạn có 5 phương thức trở xuống thì điều đó cho tôi biết rằng mã thiết lập của bạn đang làm quá nhiều hoặc các đối tượng của bạn lớn bất thường .

Nếu bạn chưa thử hãy xem mẫu trình xây dựng để xây dựng các đối tượng của mình - điều này có thể cắt giảm mã mạnh mẽ về cách bạn đang xây dựng các đối tượng của mình trước khi thử nghiệm chúng. Do đó, làm cho lớp kiểm tra đơn vị ngắn hơn và ít cần bạn cắt nó thành nhiều lớp hơn.