Tôi có kiểm tra JUnit sau đây. Phương pháp mà tôi đang thử nghiệm khá đơn giản, nó chỉ nhận được một số và trả về một List với các ước của nó. Tôi không muốn lặp lại mã kiểm tra nhiều lần, vì vậy tôi đã tạo ra một phương pháp auxiliar, testDivisorsAux:Tôi có nên chia các phương pháp để tái sử dụng trong JUnit không?
@Test
public final void testDivisors() {
testDivisorsAux(1, new int[] { 1 });
testDivisorsAux(6, new int[] { 1, 2, 3, 6 });
testDivisorsAux(0, new int[] { });
...
}
private final void testDivisorsAux(final int number, final int[] expected) {
List<Integer> divisors = Util.divisors(number);
assertSame(divisors.size(), expected.length);
for (int i : expected) {
assertTrue(divisors.contains(i));
}
}
Tất cả mọi thứ hoạt động tốt, tôi chỉ tự hỏi ... là này một thực tế xấu? Tôi có nên viết bài kiểm tra theo một cách khác không? Có thể giữ tất cả mã trong phương thức "@Test"?
PMD là nói cho tôi rằng các xét nghiệm JUnit nên bao gồm assert() hoặc không() (đối với phương pháp đầu tiên), và JUnit 4 bài kiểm tra mà thực hiện các bài kiểm tra nên sử dụng các chú thích @Test (đối với một giây) . Tôi biết rằng PMD chỉ sử dụng một biểu thức chính quy (vâng, thực ra là XPath) để xác định quy tắc nào tôi đang vi phạm ... vì vậy, tôi cho rằng đó chỉ đơn giản là cảnh báo "dương tính giả". Nhưng dù sao, tôi cũng muốn biết tôi có làm gì sai không. (Appart từ viết thử nghiệm dài hơn 4 lần so với phương pháp đang được thử nghiệm)
Trong khi tôi đang tìm kiếm câu hỏi tương tự câu hỏi này, tôi đã tìm thấy một cái gì đó gọi là parametrized tests ... kịch bản lớn hơn nhiều, phải không?
Cảm ơn bạn rất nhiều vì câu trả lời của bạn, @Adam. Tôi đã không thực sự lo lắng bởi những lời cảnh báo PMD, nhưng dù sao thì tốt để tránh chúng! :) Không chỉ là một thủ thuật hay, tôi nghĩ những cái tên bạn đề xuất cũng mang tính mô tả hơn tôi ... – AJPerez