Tôi nên giả định điều gì trong các thử nghiệm của một ứng dụng với tầng dịch vụ và tầng DAO?

Các lớp học của tôi đang theo cấu trúc này

• Tầng dịch vụ (tạo và ánh xạ dữ liệu InputDTO sang DB)
• Cấp DAO (thực tế thực hiện các cuộc gọi DB)

Khi tôi viết các bài kiểm tra JUnit của tầng dịch vụ, tầng DAO được gọi và điều này mong đợi một kết nối DB thực tế và nhận dữ liệu từ DB.

Tôi có nên chế giễu tầng DAO hoàn toàn khỏi tầng dịch vụ hay tôi nên chế giễu kết nối DB và dữ liệu nhận được từ DB?

Thứ hai, ứng dụng mong đợi một số dữ liệu nhất định từ bộ đệm.

Đối với thời gian chạy JUnit, không có bộ đệm, vậy nên xử lý như thế nào? Phương thức tầng dịch vụ bao gồm tra cứu bộ đệm để lấy thông tin chi tiết.

Tôi sẽ nói về Kiểm tra nhân đôi, nếu bạn chưa chạy qua thuật ngữ này thì có lẽ bạn sẽ muốn đọc liên kết bài viết của Martin Fowler trước.

• Đối với thử nghiệm Cơ sở dữ liệu - Nếu bạn đang theo một phương pháp thử nghiệm Đơn vị thuần túy thì bạn sẽ sử dụng Stub hoặc Mock loại Test Double để thử kết nối DB và các phản hồi của nó. Nếu bạn đang sử dụng Mock thì tôi khuyên bạn nên sử dụng Mockito, JMock hoặc công cụ giả định yêu thích khác của bạn. Tuy nhiên, điều này khá tốn công khi kiểm tra tài nguyên của bên thứ ba lớn như cơ sở dữ liệu.

• Đối với kiểm tra cơ sở dữ liệu - Nếu bạn đang theo định nghĩa thử nghiệm đơn vị lỏng lẻo hơn một chút, thì bạn có thể sử dụng Fake Test Double. Trong trường hợp cụ thể của bạn, đây sẽ là một cơ sở dữ liệu trong bộ nhớ, chẳng hạn như HSQL. Đây là một cách rất phổ biến để 'đơn vị' kiểm tra lớp cơ sở dữ liệu của bạn. Một số người sẽ cho rằng đây không phải là thử nghiệm đơn vị và thay vào đó là thử nghiệm tích hợp. Tôi nghĩ điều đó thực sự ổn - thực tế của vấn đề là, bạn có một số bài kiểm tra mã hóa mã của bạn :-)

• Đối với kiểm tra bộ đệm - Kiểu Stub của Test Double có thể là bạn của bạn ở đây - tùy thuộc vào mức độ phức tạp của API bộ đệm.

HTH!

Trong phần tóm tắt câu trả lời khá đơn giản.

Bạn có ba lớp.

[Trường hợp thử nghiệm] -> [Hành vi được thử nghiệm] -> [Các cộng tác viên được sử dụng bởi hành vi đó]

Lớp thứ ba là những gì nên được chế giễu. Ví dụ:

1. cái PokemonCaptureServiceTest;
2. xét nghiệm PokemonCaptureService;
3. trong đó sử dụng Pokeball

Trong ví dụ này hóa ra đó Pokeballlà logic của bên thứ ba. Nó yêu cầu tất cả các loại hệ thống ống nước như kết nối cơ sở dữ liệu và tệp thuộc tính, v.v. Bạn tin rằng bên thứ ba của bạn đã kiểm tra nó một cách thích hợp, vì vậy bạn muốn bỏ qua nó khỏi thử nghiệm của mình PokemonCaptureService. Do đó nó nên bị chế giễu.

Tuy nhiên, ở một thời gian và địa điểm khác, cộng tác viên Pokeballlà một lớp đơn giản giới thiệu rất ít sự phức tạp vào trường hợp thử nghiệm và có thể được đưa vào thử nghiệm một cách dễ dàng. Trong trường hợp này, bạn có thể quyết định đưa vào một ví dụ thực tế Pokeballtrong PokemonCaptureServicetrường hợp đang được thử nghiệm.

Không có luật chuyên chế. Tùy thuộc vào bạn để thiết kế các bài kiểm tra của bạn theo cách có vẻ tốt nhất cho bạn. Mục tiêu của bạn là tạo ra các bài kiểm tra chính xác và có thể duy trì càng nhanh càng tốt. Kinh nghiệm là chìa khóa ở đây. Viết thêm các bài kiểm tra và bạn sẽ sớm có được một trực giác tốt cho nó.

Thật khó để nói chính xác những gì bạn muốn kiểm tra bởi vì đánh giá từ câu hỏi bạn đang ở khắp mọi nơi. Do đó, thật khó để đưa ra bất kỳ ví dụ thực tế nào về cách tiến hành ngoài việc dẫn bạn đến các bài viết về cách chế nhạo công cụ. Vì vậy, bạn cần phải cụ thể hơn và phân chia mọi thứ một chút:

• Bạn có muốn kiểm tra để bộ đệm hoạt động đúng không?

• Bạn có muốn kiểm tra một số cuộc gọi DB nói riêng không?

• Bạn có muốn kiểm tra ứng dụng để ứng dụng sử dụng bộ đệm chính xác không?

Khi bạn quyết định chính xác đơn vị nào bạn muốn kiểm tra, sau đó chọn những gì để giả lập trở nên dễ dàng: trong thử nghiệm đơn vị thuần túy, mọi thứ trừ "đơn vị đang thử nghiệm" sẽ bị chế giễu. Lý do đằng sau điều này là bạn có thể chắc chắn từ những kỳ vọng của mình đối với các giả định mà đơn vị được thử nghiệm hoạt động như bình thường.

Ngoài ra, bạn có thể muốn viết một số bài kiểm tra trong JUnit là các bài kiểm tra tích hợp, tức là sử dụng ít giả hơn. Ngay cả khi chúng được sử dụng làm kiểm tra độ tỉnh táo để xem thiết kế phần mềm có đúng hay không, bạn nên biết rằng chúng sẽ dễ vỡ và sẽ không đưa ra bất kỳ chỉ số nào về chính xác những gì sai với ứng dụng hoặc hệ thống của bạn.