Dữ liệu thử nghiệm phức tạp liên tục

Question

Chúng tôi đang sử dụng mẫu trình tạo để tạo dữ liệu thử nghiệm. Các đối tượng miền này có quan hệ giữa chúng. Các bài kiểm tra chức năng của chúng tôi yêu cầu các đối tượng này phải được duy trì.

Hãy suy nghĩ về mô hình này:

domain model http://i34.tinypic.com/21mg1gn.png

Nếu tôi muốn có một ví dụ đơn giản của CI làm aNew().c().build()

Nếu tôi muốn nó được tiếp tục tồn tôi làm aNew().c().saveIn(session)

Nếu tôi muốn một ví dụ về C có BI được biết là aNew().c().with(b).build()

Vâng, bạn có anh ấy nghĩ. Vấn đề của tôi là, nếu tôi muốn tồn tại một C, nó có nên tồn tại không? Hoặc nó nên được tiếp tục tồn tại trước khi tay? Điều gì sẽ xảy ra nếu tôi muốn có B mặc định hợp lý? Điều gì về nếu tôi muốn tồn tại một D? Nó có nên tồn tại tất cả A, B, C không?

Tất nhiên hệ thống thực sự phức tạp hơn nhiều (đôi khi có tham chiếu vòng tròn). Tôi đang tìm cách thực hành tốt nhất để duy trì dữ liệu thử nghiệm phức tạp.

Chỉnh sửa: Có vẻ như tôi đã gặp phải rào cản ngôn ngữ, ngôn ngữ mẹ đẻ của tôi không phải là tiếng Anh, vì vậy tôi xin lỗi vì sự tối tăm. Dưới đây là thông tin thêm:

• Nó không phải là mã di sản mà tôi đang cố gắng thử nghiệm
• Tôi cố gắng để viết một bài kiểm tra vùng phủ sóng, không một thử nghiệm đơn vị (như là kết quả tôi sẽ không được chế giễu bất cứ điều gì)
• Phần mềm tôi đang cố gắng kiểm tra các công trình nếu cơ sở dữ liệu được điền vào một số mở rộng (nó không sử dụng tất cả các thực thể).

PS. Xin đừng ngần ngại hỏi thêm thông tin, bởi vì tôi đã đấu tranh để tìm ra cách thực hành tốt nhất có thể. Điều gần nhất tôi đã đưa ra là:

1. Theo dõi những gì đã được đặt rõ ràng khi xây dựng một thực thể.
2. Giả sử rằng các thực thể được đặt rõ ràng đã tồn tại, không tồn tại chúng.
3. Kiên trì mọi thứ khác (với sự riêng tư của họ).

Điều này sẽ hiệu quả nhưng cảm giác nhện của tôi đang ngứa ran, tôi sẽ làm điều gì sai vì sẽ có logic liên quan đến mã thử nghiệm, sẽ rất phức tạp.

Chỉnh sửa 2: Tôi sẽ cố gắng làm cho bản thân mình rõ ràng hơn. Khi tôi viết/chạy đơn vị của tôi và một số thử nghiệm tích hợp, tôi không có vấn đề gì, bởi vì dữ liệu thử nghiệm không được duy trì, nó tồn tại trong bộ nhớ.

Nhưng khi tôi cố gắng duy trì dữ liệu thử nghiệm của mình, hibernate sẽ không cho phép tôi lưu một thực thể mà không có mối quan hệ của nó.

Làm cách nào để khắc phục sự cố này?

Answer 1

Bạn cần phải xác định thác của bạn trên miền tốt hơn. Nếu bạn không thể kiểm tra nó, làm thế nào để bạn mong đợi nó sẽ thực hiện trong ứng dụng thực tế?

Ví dụ:

A -> B: Ai là chủ sở hữu của mối quan hệ này? Bạn có muốn thêm B vào A hay cách khác không? Đây có thể là một chi tiết thực hiện mà bạn có thể có cả B.SetParent (A) và A.Children.Add (B), và nơi bạn đặt B của cha mẹ thành A trong trường hợp A.Children.Add (B) (tương tự như vậy cách xung quanh). Điều gì sẽ xảy ra nếu bạn làm:

A a1 = new A(); 
A a2 = new A(); 
B b = new B(); 
a1.Children.Add(b); 
b.SetParent(a); 

Bạn cần phải quyết định tại đây. Không có giải pháp nào là hoàn hảo, vì vậy về cơ bản sở thích cá nhân và tính nhất quán của ứng dụng áp dụng ở đây.

Làm việc với ORM bạn gặp phải các vấn đề ràng buộc này nhanh hơn với SQL đơn giản (hoặc bất kỳ nguồn dữ liệu nào khác như XML hoặc nguồn dữ liệu của riêng bạn), nhưng bạn cần xem xét các vấn đề nếu bạn viết SQL đơn giản.

Tôi xin lỗi, tôi không có câu trả lời rõ ràng cho bạn, nhưng với tôi có vẻ như bạn cần xem xét một số ràng buộc (tôi đoán) bạn chưa làm.

Cá nhân, tôi thích kiểu kho lưu trữ khi xử lý bằng NHibernate trong DAL. Tôi làm cho kho của tôi thực hiện từ IDisposable và cho phép họ có được một phiên mỗi. Bằng cách này, bạn sẽ nhận được mẫu "Unit of work" trong thiết kế của bạn.

Chúc may mắn với nó :)

Answer 2

Bạn có thể mô tả chi tiết hơn về thiết lập thử nghiệm của mình.Cụ thể, lý do tại sao làm các xét nghiệm chức năng của bạn yêu cầu các đối tượng này phải được duy trì? Bạn có đang thử nghiệm hoạt động tồn tại thực tế không? Hay đó chỉ là một tác dụng phụ của việc chạy thử nghiệm? Bạn có muốn tải các đối tượng được lưu giữ lâu bền như một phần của các thử nghiệm của mình không?

Vấn đề của tôi là, nếu tôi muốn tồn tại một C, nó có nên tồn tại không? Hoặc nó nên được tiếp tục tồn tại trước khi tay?

Điều này sẽ phụ thuộc vào lý do bạn bền bỉ ngay từ đầu. Nếu bạn đang tích hợp kiểm tra lớp kiên trì, thì bạn chỉ nên sử dụng logic mà bản thân ứng dụng sử dụng. Nếu đó chỉ là một tác dụng phụ của thử nghiệm, bạn có thể muốn thử lớp kiên trì, v.v ...

Answer 3

• Các thử nghiệm của bạn cho bạn biết điều gì?
• Có vẻ như bạn đang thử nghiệm một ứng dụng cũ?
• Vì vậy, chức năng lấy của bạn đã được viết trong cơ sở mã của bạn và cố gắng tạo thử nghiệm bảo hiểm?

Hãy cho chúng tôi một số thông tin phản hồi chi tiết xin

Answer 4

Tôi đã tách câu trả lời của bạn theo chủ đề.

Vấn đề của tôi là, nếu tôi muốn kéo dài một C, cần kiên trì nó B? Điều gì về nếu tôi muốn tồn tại một D? Nó có nên tồn tại tất cả A, B, C không?

Điều này hoàn toàn phụ thuộc vào các hạn chế về miền bạn chọn để thực thi.Ví dụ: là C một thực thể và B một đối tượng giá trị? Nói cách khác, không C có bản sắc và cuộc sống riêng không? Có phải B được xác định chủ yếu bởi giá trị của nó và vòng đời của nó được kết hợp chặt chẽ với giá trị của số gốc C?

Yêu cầu các loại câu hỏi này sẽ giúp hướng dẫn các quyết định của bạn về những gì cần tồn tại, khi nào và bởi ai.

Ví dụ, nếu cả hai C và B là các đơn vị chia sẻ chỉ là một mối quan hệ, bạn có thể quyết định kéo dài chúng independantly, vì mỗi hình dung có thể có một cuộc sống có ý nghĩa và bản sắc riêng của mình. Nếu B là một đối tượng giá trị, bạn có thể chọn để có thực thể cha mẹ của nó C kiểm soát cuộc sống của nó, bao gồm tạo/truy xuất/cập nhật/xóa đối tượng. Điều này có thể rất tốt bao gồm C bền bỉ B.

Hoặc nó có nên tiếp tục tồn tại trước khi bàn tay không?

Để trả lời điều này, bạn có thể phải vạch ra các phụ thuộc đối tượng của mình. Những phụ thuộc này thường được biểu diễn bằng các ràng buộc khóa ngoài khi một biểu đồ đối tượng được duy trì tới một RDBMS. Nếu C không thể hoạt động mà không có tham chiếu đến B, thì có thể bạn sẽ muốn duy trì cả hai bên trong giao dịch, trước tiên hãy thực hiện B trước để tuân thủ các ràng buộc khóa ngoại của cơ sở dữ liệu. Sau khi dòng suy nghĩ trên, nếu B là một thực thể trẻ hoặc đối tượng giá trị của C, bạn thậm chí có thể có C chịu trách nhiệm về sự bền bỉ B.

Còn nếu tôi muốn mặc định hợp lý B thì sao?

Việc tạo ra B trường hợp có thể được giao cho B -Nhà máy. Cho dù bạn thực hiện logic nhà máy này như là một phương thức (không phải ví dụ) của lớp, hàm tạo hoặc tách nó ra làm đơn vị riêng của nó không quan trọng. Vấn đề là bạn có một nơi tạo và cấu hình mới B s diễn ra. Đó là ở nơi này mà bạn sẽ có một cấu hình mặc định của đối tượng mới được tạo ra.

Một nguồn tuyệt vời bao gồm những loại câu hỏi là Domain-Driven Design bởi Eric Evans

Answer 5

Tôi không chắc tôi hiểu vấn đề bạn đang cố gắng để giải quyết rất tốt nhưng ... những gì về serializing toàn bộ đồ thị dưới dạng XML sử dụng một cái gì đó như XStream hoặc của Google Protocol Buffers?

Answer 6

Theo tôi thấy vấn đề là với miền của bạn (như bạn đã vẽ nó). Theo như tôi understanf nó C có một mối quan hệ của nhiều-to-một đến B, và cơ sở dữ liệu được enfocing nó bằng một lĩnh vực ngoại khóa không nullable.Mặt khác, từ mã trong câu hỏi, tôi có thể hiểu rằng không có nguyên tắc thi hành chính xác một quy tắc trong mã, và thành viên tham chiếu đến cá thể B trong cá thể C có thể là null. Theo tôi hiểu mô hình miền phải luôn luôn đúng trong mã và trong thời gian chạy, vì vậy nếu quy tắc này có thể được thực thi trong mã (bằng cách yêu cầu tham chiếu B trong phương thức C build()), bạn sẽ không có bất kỳ vấn đề nào với sự kiên trì - bạn chỉ có thể kiên trì tất cả.

Giải pháp khác, nhiều bụi bẩn hơn sẽ chỉ là lập trình bỏ tất cả các ràng buộc DB gây rối với kiểm tra của bạn trước khi thử nghiệm và khôi phục chúng sau đó. Tất nhiên nó sẽ làm cho DB hoàn toàn không sử dụng được bất cứ điều gì khác chạy trong parralel để kiểm tra, nhưng điều này có thể được giải quyết bằng cách sử dụng một interated DB như SQLite hoặc SQL Server Compact Edition chỉ cho các bài kiểm tra.