Đơn vị kiểm tra một phương thức void

Để sửa lỗi trong một ứng dụng, tôi đã sửa đổi một phương thức được đặt tên postLoginbằng cách thêm một cuộc gọi vào một phương thức hiện có tên getShoppingCart.

Mã

protected void postLogin() {
  getShoppingCart();
}

Tuy nhiên, tôi không chắc cách tốt nhất để viết bài kiểm tra đơn vị postLoginlà gì.

Cách tiếp cận 1

Sử dụng xác minh từ Mockito để chỉ cần xác minh rằng phương thức đã được gọi.

verify(mock).getShoppingCart();

Cách tiếp cận 2

Kiểm tra tác dụng phụ của lệnh gọi phương thức bằng cách tìm nạp giá trị của giỏ hàng của người dùng.

AssertNotNull(user.getShoppingCart());

Là một cách tiếp cận tốt hơn so với cách khác?

Tôi thường thích phương pháp 2.

Tại sao? Bởi vì, bạn muốn postLoginthay đổi một số trạng thái của hệ thống của mình, nhưng cách nó thực hiện điều này (và phương thức mà nó gọi trong nội bộ này) chỉ là một chi tiết triển khai, không có gì mà bài kiểm tra đơn vị của bạn đưa ra bất kỳ giả định nào. Vì vậy, tốt hơn làm cho bài kiểm tra của bạn chỉ cần xác minh trạng thái cuối cùng.

Tôi sẽ thay đổi getShoppingCart thành một cái gì đó như initizeShoppingCart, mục đích của phương pháp sẽ rõ ràng với bất kỳ ai đọc nó mà không cần kiểm tra phương thức nào và tác dụng phụ như thế này có thể gây ra một số hành vi đáng ngạc nhiên cho người dùng phương pháp.

Nếu getShoppingCart thuộc một lớp khác và nó đã được thử nghiệm đơn vị, tôi sẽ sử dụng phương pháp 1 - không cần phải kiểm tra lại những gì đã thử nghiệm. Trong trường hợp này, chúng tôi chắc chắn rằng getShoppingCart hoạt động chính xác và chúng tôi chỉ muốn đảm bảo rằng nó được gọi từ postLogin vì vậy nếu ai đó trong tương lai xóa cuộc gọi này, thử nghiệm sẽ thất bại.

Nếu getShoppingCart là một phương thức riêng không thể tự kiểm tra được, thì tôi sẽ sử dụng phương pháp 2, để đảm bảo rằng khi postLogin được gọi là chức năng mong muốn của getShoppingCart được thực hiện như mong đợi.

Khi kiểm tra một lệnh gọi hàm (void or not) có tác dụng phụ, hoàn toàn nhất để kiểm tra rằng hiệu ứng phụ không chỉ xảy ra, mà còn để kiểm tra xem tác dụng phụ (đầu ra hệ thống hoặc thay đổi trạng thái) là mong muốn.

Tôi sẽ không thảo luận về thiết kế của bạn, nhưng trong trường hợp của bạn, tôi sẽ chọn cách tiếp cận đầu tiên bởi vì thử nghiệm đơn vị là để thử nghiệm phương pháp nào về mặt kỹ thuật bất kể công việc của họ trong miền là gì, đó là phương pháp của bạn postLoginlàm gì? Về mặt kỹ thuật, nó gọi getShoppingCardđể bạn phải kiểm tra xem thực sự đang gọi getShoppingCard, tôi cũng sẽ tạo một thử nghiệm khác getShoppingCardđể kiểm tra xem nó có tác dụng gì và nếu nó có tác dụng phụ, tôi sẽ kiểm tra bên trong thử nghiệm mới đó.

Bạn có một lỗi trong postLogin. Vì vậy, điều đầu tiên bạn nên làm là tạo một bài kiểm tra đơn vị mà khi gọi postLogin mà không có bộ thông tin dự kiến ​​sẽ "thất bại".

Từ ý tưởng trên, một phương án khác trong số 2 đề xuất là đưa thông tin về giỏ hàng làm thông số. Nếu bạn không có thông tin chính xác, bạn sẽ ném một ngoại lệ không được kiểm tra. Điều này sẽ làm rõ rằng nếu không có các chi tiết chính xác, phương pháp của bạn sẽ bị tiêu diệt.

Điều này sẽ yêu cầu một chút thay đổi trong đó khách hàng gọi postLogin ngay bây giờ cũng được yêu cầu để vượt qua thông tin giỏ hàng. Đối với tôi điều này vẫn còn mạch lạc khi bạn thấy chúng được ghép nối. Khớp này sẽ được thực hiện bởi người gọi.

Sau đó, bạn thậm chí sẽ không cần kiểm tra getShoppingCart bên trong postLogin vì phương thức thực sự được kiểm tra là postLogin. Đây là một lỗi có lỗi và là lỗi duy nhất yêu cầu sửa lỗi và xác nhận hợp lệ. Với sự phụ thuộc được tiêm, bạn sẽ có thể kiểm tra nó dễ dàng trong các điều kiện khác nhau và xác nhận rằng không có lỗi nào được đưa ra.