Tôi đã viết một số bài kiểm tra đơn vị cho một số mã mới tại nơi làm việc và đã gửi nó đi để xem xét mã. Một trong những đồng nghiệp của tôi đã đưa ra nhận xét về lý do tại sao tôi đặt các biến được sử dụng trong một số thử nghiệm ngoài phạm vi cho thử nghiệm.
Mã tôi đã đăng về cơ bản là
import org.junit.Test;
public class FooUnitTests {
@Test
public void testConstructorWithValidName() {
new Foo(VALID_NAME);
}
@Test(expected = IllegalArgumentException.class)
public void testConstructorWithNullName() {
new Foo(null);
}
@Test(expected = IllegalArgumentException.class)
public void testConstructorWithZeroLengthName() {
new Foo("");
}
@Test(expected = IllegalArgumentException.class)
public void testConstructorWithLeadingAndTrailingWhitespaceInName() {
final String name = " " + VALID_NAME + " ";
final Foo foo = new Foo(name);
assertThat(foo.getName(), is(equalTo(VALID_NAME)));
}
private static final String VALID_NAME = "name";
}Những thay đổi được đề xuất của ông về cơ bản là
import org.junit.Test;
public class FooUnitTests {
@Test
public void testConstructorWithValidName() {
final String name = "name";
final Foo foo = new Foo(name);
}
@Test(expected = IllegalArgumentException.class)
public void testConstructorWithNullName() {
final String name = null;
final Foo foo = new Foo(name);
}
@Test(expected = IllegalArgumentException.class)
public void testConstructorWithZeroLengthName() {
final String name = "";
final Foo foo = new Foo(name);
}
@Test(expected = IllegalArgumentException.class)
public void testConstructorWithLeadingAndTrailingWhitespaceInName() {
final String name = " name ";
final Foo foo = new Foo(name);
final String actual = foo.getName();
final String expected = "name";
assertThat(actual, is(equalTo(expected)));
}
}Trong đó mọi thứ được yêu cầu trong phạm vi thử nghiệm, được xác định trong phạm vi thử nghiệm.
Một số lợi thế mà ông lập luận là
- Mỗi bài kiểm tra là khép kín.
- Mỗi thử nghiệm có thể được thực hiện trong sự cô lập, hoặc tổng hợp, với cùng một kết quả.
- Người kiểm tra không phải cuộn đến bất cứ nơi nào các tham số này được khai báo để tra cứu giá trị là gì.
Một số nhược điểm của phương pháp mà tôi lập luận là
- Tăng sao chép mã
- Có thể thêm nhiễu vào tâm trí người đánh giá nếu có một số thử nghiệm tương tự với các giá trị khác nhau được xác định (nghĩa là thử nghiệm với
doFoo(bar)kết quả trong một giá trị, trong khi cùng một cuộc gọi có kết quả khác nhau vìbarđược định nghĩa khác nhau trong phương thức đó).
Ngoài quy ước, có bất kỳ lợi thế / bất lợi nào khác của việc sử dụng phương pháp này so với phương pháp khác không?
Vấn đề duy nhất tôi thấy với mã của bạn là bạn đã chôn phần khai báo của VALID_NAME ở phía dưới khiến chúng tôi tự hỏi nó đến từ đâu. Sửa nó sẽ chăm sóc "cuộn". Tên phạm vi địa phương đồng nghiệp của bạn đang vi phạm DRY mà không có lý do. Hỏi anh ta tại sao nên sử dụng các câu lệnh nhập bên ngoài mỗi phương thức kiểm tra. Sheesh nó được gọi là bối cảnh.
—
candied_orange
@CandiedOrange: không có ai ở đây đọc câu trả lời của tôi? Cách tiếp cận đồng nghiệp có thể vi phạm nguyên tắc DRY, nhưng không phải trong ví dụ này. Không có điểm nào có cùng một "tên" văn bản trong tất cả các trường hợp này.
—
Doc Brown
Các biến bổ sung không thêm rõ ràng, tuy nhiên, điều đó chỉ ra rằng bạn có thể viết lại các bài kiểm tra của mình để sử dụng Lý thuyết và Dữ liệu của Junit, điều này sẽ làm giảm các bài kiểm tra của bạn rất nhiều!
—
Rosa Richter
@CandiedOrange: DRY ít liên quan đến việc tránh sao chép mã hơn là tránh trùng lặp kiến thức (sự kiện, quy tắc, v.v.). Xem: hermanradtke.com/2013/02/06/misunder Hiểu-dry.html Nguyên tắc Dry được nêu là "Mỗi phần kiến thức phải có một đại diện duy nhất, rõ ràng, có thẩm quyền trong một hệ thống." vi.wikipedia.org/wiki/Don%27t numpeat_yourself
—
Marjan Venema
Hầu hết mọi kiến thức đều phải có một đại diện duy nhất, rõ ràng, có thẩm quyền trong một hệ thống. Vậy thực tế "tên" là một VALID_NAME KHÔNG phải là một trong những kiến thức này? Đúng là DRY không chỉ tránh việc sao chép mã mà bạn sẽ thấy khó có thể DRY với mã trùng lặp.
—
candied_orange