Kiểm thử đơn vị lớp tiện ích

Tất cả chúng ta đều có một số lớp tiện ích, chỉ chứa các phương thức tĩnh, để sử dụng từ các nguồn khác nhau. Bây giờ, có thể có hai cách tiếp cận có thể được thực hiện để kiểm tra đoạn mã này.

Cách tiếp cận 1:

Có các bài kiểm tra đơn vị riêng cho các lớp tiện ích. Bất cứ nơi nào họ được gọi, hãy giả sử sự tương tác của họ bằng cách sử dụng một số khung kiểm tra có cung cấp cho nó, chẳng hạn như PowerMock. Điều này về cơ bản coi lớp tiện ích là một thành phần riêng biệt của hệ thống, cần được kiểm tra và bảo trì riêng lẻ.

Cách tiếp cận 2:

Không viết bài kiểm tra đơn vị cho các lớp tiện ích. Tuy nhiên, các thử nghiệm được viết cho các lớp cốt lõi khác của bạn tương tác với lớp tiện ích này, hãy để sự tương tác đó xảy ra, về cơ bản sẽ đảm bảo rằng mã được viết trong lớp tiện ích này được kiểm tra chính xác cho các giai đoạn khác nhau. Nếu một cái gì đó bị phá vỡ, các bài kiểm tra cho các thành phần khác sẽ có thể bắt được nó.

Vui lòng chia sẻ suy nghĩ của bạn về cách tiếp cận nào là thích hợp hơn, hoặc nếu có một số cách khác mà mọi người đi về vấn đề này.

Tôi nghĩ rằng có một sự hiểu lầm lớn về các lớp 'tiện ích' ngoài kia. Chỉ vì bạn tạo một lớp 'tĩnh', nó không biến nó thành một lớp tiện ích. Nếu lớp tiện ích tĩnh của bạn có các phụ thuộc (có thể tự biểu hiện trong các lớp 'tiện ích' tĩnh khác), nó sẽ đưa ra các tác dụng phụ hoặc hành vi của nó không thể được kiểm soát hoàn toàn bởi các đầu vào của nó không phải là lớp tiện ích.

Các lớp tiện ích thực sự không cần phải bị chế giễu vì đầu ra của chúng luôn mang tính xác định tùy thuộc vào đầu vào của chúng.

Kiểm thử đơn vị là về việc khởi tạo một phần nhỏ trong ứng dụng của bạn (một đơn vị) để bạn có thể (có khả năng) kiểm tra tất cả các đường dẫn mã trong đơn vị đó. Mocking phụ thuộc đạt được sự cô lập này. Nếu một lớp tiện ích phá vỡ sự cô lập, một lần nữa nó không phải là một lớp tiện ích vì một lớp tiện ích được cho là bị cô lập theo định nghĩa.

Vì vậy, trong một ứng dụng, người ta không bao giờ muốn hoặc phải chế nhạo các lớp tiện ích. Các lớp mà bạn cảm thấy cần phải bị chế giễu cần phải được chuyển thành các lớp khả thi của lớp đầu tiên và cần được chuyển vào đơn vị như một phần phụ thuộc (Xem phần phụ thuộc tiêm ). Những phụ thuộc này sau đó có thể được chế giễu một cách dễ dàng để đơn vị có thể được kiểm tra một cách cô lập.

Theo ý kiến ​​của tôi, thật nực cười khi chế nhạo một sự phụ thuộc vào một phương thức tiện ích tĩnh cho những thứ như tách chuỗi.

Có, nếu phương thức bộ chia sai, nó có thể gây ra lỗi giả trong các thử nghiệm cho các phương thức không liên quan đến việc tách chuỗi. Nhưng đó không phải là điểm của một bộ thử nghiệm. Bộ thử nghiệm phải thành công 100%, thời gian. Nếu không, bạn sửa những gì bị hỏng và lặp lại cho đến khi thành công 100%. Nếu lớp chuỗi tiện ích bị hỏng thì nó ngay lập tức nên gây ra một sự thất bại trong một bài kiểm tra đó là về chức năng chuỗi. Bạn sửa chức năng đó và sau đó tất cả các lỗi đều biến mất, do đó bạn thậm chí không bao giờ phải xem xét các trường hợp thử nghiệm thất bại giả.

Nói cách khác, CÓ, viết các bài kiểm tra cho các phương thức tiện ích. KHÔNG, đừng cố tách chúng ra khỏi các bài kiểm tra khác. Đơn giản chỉ cần giả định rằng các chức năng tiện ích tầm thường hoạt động chính xác, như được xác minh bằng các thử nghiệm của riêng họ. Làm bất cứ điều gì nhiều hơn là nỗ lực nhiều hơn để không đạt được bất cứ điều gì.