Làm cách nào để bạn quản lý dữ liệu giả được sử dụng cho thử nghiệm? Giữ chúng với các thực thể tương ứng của chúng? Trong một dự án thử nghiệm riêng biệt? Tải chúng bằng Serializer từ các tài nguyên bên ngoài? Hoặc chỉ cần tạo lại chúng bất cứ nơi nào cần thiết?Dữ liệu giả và chiến lược thử nghiệm đơn vị trong ngăn xếp ứng dụng mô-đun
Chúng tôi có một ngăn xếp ứng dụng với một số mô-đun tùy thuộc vào một mô-đun khác với từng thực thể có chứa. Mỗi mô-đun có các thử nghiệm riêng và cần dữ liệu giả để chạy.
Bây giờ, một mô-đun có nhiều phụ thuộc sẽ cần nhiều dữ liệu giả từ các mô-đun khác. Tuy nhiên, những người này không xuất bản các đối tượng giả của họ vì chúng là một phần của tài nguyên thử nghiệm nên tất cả các mô-đun phải thiết lập tất cả các đối tượng giả mà họ cần lặp đi lặp lại.
Ngoài ra: hầu hết các lĩnh vực vào đơn vị của chúng tôi không nullable để giao dịch thậm chí chạy so với lớp đối tượng đòi hỏi họ phải chứa một số giá trị, phần lớn thời gian với những hạn chế hơn nữa như độc nhất, chiều dài vv
Có cách thực hành tốt nhất trong số này hoặc là tất cả các giải pháp thỏa hiệp?
More Detail
ngăn xếp của chúng tôi trông giống như sau:
Một Module:
src/main/java --> gets jared (.../entities/*.java contains the entities)
src/main/resources --> gets jared
src/test/java --> contains dummy object setup, will NOT get jared
src/test/resources --> not jared
Chúng tôi sử dụng Maven để xử lý phụ thuộc.
mô-đun dụ:
- Module Một có một số đối tượng giả
- Module B cần đối tượng riêng của mình và giống như Module Một
Lựa chọn một)
Mô-đun thử nghiệm T có thể chứa tất cả các đối tượng giả và cung cấp cho chúng trong phạm vi kiểm tra (do đó phụ thuộc tải không bị kẹt) cho tất cả các thử nghiệm trong tất cả các Mô-đun. Công việc vừa ý? Ý nghĩa: Nếu tôi tải T ở Một và chạy cài đặt trên Một nó sẽ KHÔNG chứa các tham chiếu được giới thiệu bởi T đặc biệt là không B? Sau đó, tuy nhiên A sẽ biết về B datamodel B.
Lựa chọn b)
mô-đun A cung cấp các đối tượng giả ở đâu đó trong src/main/java../entities/dummy phép B để có được chúng trong khi Một không biết về dữ liệu giả B 's
Tùy chọn c)
Mọi mô-đun đều chứa các tài nguyên bên ngoài được các đối tượng giả được tuần tự hóa. Chúng có thể được deserialized bởi môi trường thử nghiệm cần chúng bởi vì nó có sự phụ thuộc vào module mà chúng thuộc về. Điều này sẽ yêu cầu tất cả các mô-đun để tạo và serialize các đối tượng giả của nó mặc dù và làm thế nào sẽ làm điều đó? Nếu với một bài kiểm tra đơn vị khác, nó giới thiệu các phụ thuộc giữa các bài kiểm tra đơn vị mà không bao giờ nên xảy ra hoặc với một kịch bản sẽ khó để gỡ lỗi và không linh hoạt.
Lựa chọn d)
Sử dụng một khuôn khổ giả và giao cho các trường bắt buộc bằng tay cho mỗi bài kiểm tra khi cần thiết. Vấn đề ở đây là hầu hết các trường trong thực thể của chúng ta không phải là nullable và do đó sẽ yêu cầu setters hoặc constructors được gọi để kết thúc chúng ta lại ở đầu một lần nữa.
Những gì chúng ta không muốn
Chúng tôi không muốn thiết lập một cơ sở dữ liệu tĩnh với dữ liệu tĩnh như cấu trúc các đối tượng cần sẽ liên tục thay đổi. Rất nhiều ngay bây giờ, một chút sau đó. Vì vậy, chúng tôi muốn hibernate để thiết lập tất cả các bảng và cột và điền vào những người có dữ liệu tại thời gian thử nghiệm đơn vị. Ngoài ra một cơ sở dữ liệu tĩnh sẽ giới thiệu rất nhiều lỗi tiềm năng và kiểm tra các phụ thuộc lẫn nhau.
Suy nghĩ của tôi có đi đúng hướng không? Cách tốt nhất để giải quyết các bài kiểm tra yêu cầu nhiều dữ liệu là gì? Chúng tôi sẽ có một số mô-đun phụ thuộc lẫn nhau sẽ yêu cầu các đối tượng chứa đầy một số loại dữ liệu từ một số mô-đun khác.
EDIT
Một số thông tin thêm về cách chúng tôi đang làm việc đó ngay bây giờ để đáp ứng với câu trả lời thứ hai:
Vì vậy, để đơn giản, chúng tôi có ba mô-đun: Person, Product, Order. Person sẽ kiểm tra một số phương pháp quản lý sử dụng một đối tượng MockPerson:
(trong người/src/kiểm tra/java :)
public class MockPerson {
public Person mockPerson(parameters...) {
return mockedPerson;
}
}
public class TestPerson() {
@Inject
private MockPerson mockPerson;
public testCreate() {
Person person = mockPerson.mockPerson(...);
// Asserts...
}
}
Lớp MockPerson sẽ không được đóng gói.
cũng áp dụng cho thử nghiệm sản phẩm:
(trong sản phẩm /src/kiểm tra/java :)
public class MockProduct() { ... }
public class TestProduct {
@Inject
private MockProduct mockProduct;
// ...
}
MockProduct là cần thiết nhưng sẽ không được đóng gói.
Bây giờ, Kiểm tra đơn đặt hàng sẽ yêu cầu MockPerson và MockProduct, vì vậy hiện tại chúng tôi cần tạo cả hai cũng như MockOrder để kiểm tra Order.
(trong trật tự/src/kiểm tra/java :)
Đây là những bản sao và sẽ cần phải được thay đổi mỗi khi Person hoặc Product thay đổi
public class MockProduct() { ... }
public class MockPerson() { ... }
Đây là lớp học chỉ phải ở đây:
public class MockOrder() { ... }
public class TestOrder() {
@Inject
private order.MockPerson mockPerson;
@Inject
private order.MockProduct mockProduct;
@Inject
private order.MockOrder mockOrder;
public testCreate() {
Order order = mockOrder.mockOrder(mockPerson.mockPerson(), mockProduct.mockProduct());
// Asserts...
}
}
Bộ điều khiển hiện tại, chúng tôi phải cập nhật person.MockPerson và order.MockPerson bất cứ khi nào Person bị thay đổi. Không phải là nó tốt hơn để chỉ xuất bản các Mocks với bình để mọi thử nghiệm khác mà có sự phụ thuộc anyway chỉ có thể gọi Mock.mock và có được một đối tượng thiết lập độc đáo không? Có phải không? Hay đây là mặt tối - một cách dễ dàng?
Hey cwash! Cảm ơn cho con trỏ nhà máy. Tôi nhớ sử dụng nó trong một hướng dẫn đường ray;) Đây có thể là giải pháp, tôi sẽ phải kiểm tra nó ra xa hơn. – Pete
@Pete - tuyệt, bạn có thể để lại ghi chú/cập nhật cho chúng tôi biết bạn đã quyết định điều gì không? – cwash
Vì vậy, có vẻ như chúng ta có thể sử dụng nó như một nhà cung cấp dữ liệu giả trung tâm. Tuy nhiên, cuối cùng nó chỉ là Option a) có nghĩa là một số dự án bên ngoài sẽ giữ tất cả các trình tạo dữ liệu cần thiết. Vẫn tự hỏi nếu đó là cách tốt nhất để đi. Hy vọng sẽ có thêm một số ý kiến về điều này .. – Pete