2013-04-05 54 views
5

Tôi bắt đầu viết các trường hợp kiểm tra JUnit cho một mã khối cũ. Một trong những phương thức công khai có nhiều câu lệnh if và dựa trên điều kiện nó gọi các phương thức riêng tư khác nhau.
Tôi có nên viết một phương pháp thử và kiểm tra tất cả các điều kiện không? hoặc một phương pháp cho từng điều kiện?Thực hành tốt nhất của Junit: Phương thức công khai gọi nhiều phương thức riêng tư

Tôi sẽ không mất tính nhất quán nếu tôi viết các phương pháp riêng lẻ cho từng điều kiện nếu không?

Cách tiếp cận để thử nghiệm các phương pháp riêng tư là gì? Logic phương thức riêng có thể phức tạp hơn các phương thức công khai.

Trả lời

4

Căn cứ số phương pháp về số lượng kịch bản bạn muốn kiểm tra, không có gì liên quan đến các phương pháp mà thử nghiệm đang được kiểm tra.

Nếu mỗi trường hợp có mã riêng để thiết lập, thì bạn sẽ nhận được một phương pháp thử nghiệm cho từng trường hợp. Nếu bạn có thể tham số hóa các bài kiểm tra thì bạn có thể có một phương pháp kiểm tra và truyền dữ liệu khác nhau cho từng kịch bản.

Điều quan trọng là đối với mỗi kết hợp các yếu tố đầu vào bạn muốn thử nghiệm thành công hoặc thất bại độc lập với các thử nghiệm khác. Nếu bạn shoehorn tất cả các bài kiểm tra vào một phương pháp sau đó không thể xảy ra, thất bại kiểm tra đầu tiên sẽ ngăn chặn các xét nghiệm còn lại chạy.

0

Theo quan điểm của tôi, các đơn vị nhỏ hơn trong thử nghiệm đơn vị thường dẫn đến các thử nghiệm tốt hơn. Đối với bạn, điều này có nghĩa là thay đổi các phương thức riêng tư thành gói riêng tư và viết các bài kiểm tra cho mỗi người trong số họ.

+0

Không thể làm điều đó. Đó là một mã di sản và một số logic không thể được tiếp xúc là công khai. –

+0

Tôi sẽ không thay đổi nó thành công khai, nhưng để gói riêng và đảm bảo rằng các thử nghiệm nằm trong cùng một gói (bằng cách tách nguồn sản xuất và thử nghiệm) – user2088476

1

Tôi đồng ý với Nathan. Các xét nghiệm nên đi theo các kịch bản không phải là phương pháp. Đôi khi mã di sản được viết theo cách mà bạn cần phải thử nghiệm các phương thức riêng trực tiếp. Và có, mã nên được refactored. Nhưng nếu bạn không thể cấu trúc lại hoặc muốn có một thử nghiệm ở vị trí đầu tiên ...

Lựa chọn 1 - làm cho phương pháp truy cập gói tin

Đây là một refactoring rất an toàn.

Lựa chọn 2 - sử dụng phản ánh để gọi phương thức tĩnh trực tiếp

Nếu bạn thực sự không thể chạm vào mã, đây là tốt nhất mà bạn có thể làm. Tôi muốn đặt câu hỏi về yêu cầu không chạm vào mã. Nếu chúng ta không thể cải thiện mã, chúng ta có nên để nó ở góc để thối không?

+1

có thể viết các bài kiểm tra trong Groovy (không tôn trọng quyền riêng tư) có thể là một tùy chọn khác . –

+0

@NathanHughes gợi ý tuyệt vời! –

Các vấn đề liên quan