Chúng ta có nên chế giễu các thực thể và các đối tượng giá trị khi thực hiện DDD không?


9

Sau khi đọc một vài bài viết về các đối tượng Newable vs tiêm và các khái niệm này liên quan đến các dịch vụ, thực thể và đối tượng giá trị của DDD như thế nào, tôi đã có một số nghi ngờ về việc sử dụng các vật phẩm mới trong mã của mình, đặc biệt là trong các thử nghiệm đơn vị của tôi.

Các ứng cử viên chính cho các sản phẩm mới là các đối tượng Thực thể và Giá trị có nghĩa là thay vì đưa các phụ thuộc này vào các đối tượng khác, người ta chỉ nên là newmột thể hiện của các đối tượng này và sử dụng chúng trực tiếp trong mã.

Tuy nhiên, các thực hành DDD tốt ủng hộ việc giao trách nhiệm cho các thực thể và các đối tượng giá trị nếu chúng được coi là phù hợp. Vì vậy, các thực thể và các đối tượng giá trị sẽ kết thúc có một số logic kinh doanh nghiêm túc trong đó.

Bây giờ nếu một dịch vụ hoạt động trên một thực thể hoặc một đối tượng giá trị thì tôi có nên chế nhạo đối tượng hoặc đối tượng giá trị đó và chuyển giả cho dịch vụ (giả định sẽ yêu cầu một interfaceđối tượng giá trị hoặc các thực thể dường như được ủng hộ)?

Hoặc tôi chỉ nên là newmột đối tượng thực thể / giá trị và chuyển một triển khai cụ thể cho dịch vụ và do đó vi phạm nguyên tắc thử nghiệm đơn vị chỉ thử nghiệm một đơn vị?



Nó phụ thuộc vào việc bạn là người thử nghiệm cổ điển hay người nhạo báng
jhewlett

@jhewlett Một người theo chủ nghĩa cổ điển sẽ không chế nhạo bất cứ điều gì; một kẻ nhạo báng rất có thể chỉ giả các Dịch vụ, Kho lưu trữ và Nhà máy (là "thuốc tiêm"), không bao giờ là Thực thể hoặc Đối tượng Giá trị (là "sản phẩm mới").
Rogério

@ Rogério, khi bạn nói Dịch vụ; bạn có nghĩa là Dịch vụ ứng dụng hoặc Dịch vụ tên miền?
w0051977

@Songo, bạn đã quyết định làm gì? Bạn có chế giễu: Thực thể; Đối tượng giá trị và dịch vụ miền?
w0051977

Câu trả lời:


11

Tôi đang đọc rằng bạn cho rằng các bài kiểm tra đơn vị, giống như các đối tượng RẮN, phải có "một lý do để phá vỡ". Đó là một mục tiêu cao cả, nhưng tôi nghĩ bạn sẽ thấy rằng trong nhiều trường hợp, điều đó đơn giản là không khả thi. Một trong những trường hợp đó là ở đây, nơi bạn có một đối tượng miền "giàu" (DDD phân biệt giữa các Thực thể và Đối tượng Giá trị, cả hai đều bao gồm "mô hình miền") là một phụ thuộc của hệ thống đang được thử nghiệm.

Trong những tình huống này, tôi có triết lý rằng, được đưa rađối tượng miền có phạm vi kiểm tra đơn vị toàn diện của riêng mình, tin tưởng rằng đối tượng sẽ hoạt động như được thiết kế trong một thử nghiệm đơn vị cho một SUT khác nhau không nhất thiết vi phạm thử nghiệm đơn vị. Nếu thử nghiệm này bị hỏng do thay đổi tên miền, thì tôi sẽ hy vọng thử nghiệm đơn vị của đối tượng miền cũng bị phá vỡ, dẫn tôi đến một cái gì đó để điều tra. Nếu thử nghiệm đơn vị của đối tượng miền đã được cập nhật đúng như thử nghiệm màu đỏ, sau đó chuyển sang màu xanh lục với thay đổi và thử nghiệm khác sau đó không thành công, đó cũng không hẳn là một điều xấu; điều đó có nghĩa là những kỳ vọng của thử nghiệm khác này xung đột với những kỳ vọng mới cho miền và tôi cần đảm bảo cả hai đều đồng ý với nhau và các tiêu chí chấp nhận bao quát của hệ thống.

Như vậy, tôi sẽ chỉ chế nhạo một đối tượng miền nếu đối tượng miền cho biết "tác dụng phụ" không mong muốn từ góc độ kiểm tra đơn vị (nghĩa là chạm vào tài nguyên bên ngoài như lưu trữ dữ liệu) hoặc nếu logic của đối tượng miền đủ phức tạp mà đặt nó ở trạng thái thích hợp cho bài kiểm tra trở thành vật cản để xác định và vượt qua bài kiểm tra.

Điều đó sau đó trở thành câu hỏi lái xe; cái nào dễ hơn Để sử dụng đối tượng miền cho mục đích dự định của nó trong thử nghiệm, hoặc để chế nhạo nó? Làm bất cứ điều gì dễ dàng hơn, cho đến khi nó không còn là lựa chọn dễ dàng hơn, chẳng hạn như khi thay đổi chức năng phá vỡ thử nghiệm dịch vụ theo cách phức tạp; nếu điều này xảy ra, sau đó viết lại thử nghiệm để tạo ra một bản mô tả phơi bày các yêu cầu chức năng phụ thuộc vào dịch vụ, mà không có sự phức tạp phá vỡ nó.

Hiểu theo cách nào đó, cần có một thử nghiệm tích hợp sử dụng đối tượng miền thực được cắm vào dịch vụ thực để kiểm tra sự tương tác giữa hai loại này ở mức độ trừu tượng cao hơn (ví dụ như thử nghiệm, không chỉ là chức năng đằng sau một dịch vụ điểm cuối, nhưng một proxy qua đó đối tượng miền được tuần tự hóa và gửi).


Trong DDD, "mô hình miền" cũng bao gồm Dịch vụ miền, Kho lưu trữ và Nhà máy, không chỉ các Thực thể và Đối tượng Giá trị.
Rogério

0

Tin tưởng vào lớp phụ thuộc rằng nó hoạt động đúng, hy vọng sẽ thất bại một số bài kiểm tra đơn vị khi một cái gì đó không hoạt động, sau đó nó sẽ được kiểm tra rất tốt . Có thể thiếu một số bài kiểm tra đơn vị quan trọng? Có thể có một trường hợp chưa được kiểm tra sẽ tạo ra lỗi, sẽ được tạo ra trong lớp kiểm tra nguồn gốc của tôi và sẽ không bị bắt trong chính lớp phụ thuộc.

Vì vậy, theo tôi đối với các bài kiểm tra đơn vị, các lớp phụ thuộc nên bị chế giễu. Nếu không làm như vậy, thì đó là một bài kiểm tra tích hợp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.