Tại sao chúng ta viết các đối tượng giả khi viết các trường hợp kiểm thử đơn vị?

Chúng tôi hiện đang viết trường hợp thử nghiệm đơn vị trong dự án của chúng tôi. Việc triển khai cho các phương thức cơ sở dữ liệu tồn tại và đang hoạt động tốt. Trong trường hợp này tại sao chúng ta cần phải viết các đối tượng giả? Có bất kỳ lý do cụ thể? Tại sao tôi không thể kiểm tra trực tiếp DAO?

Bạn không nên chế nhạo các cuộc gọi đến cơ sở dữ liệu vì điều đó sẽ đánh bại mục đích. Những gì bạn NÊN chế giễu, ví dụ, gọi cho DAO của bạn từ, giả sử, một lớp dịch vụ. Mocking cho phép bạn kiểm tra các phương pháp trong sự cô lập.

Giả sử bạn có một mô phỏng nhà hàng với kiến ​​trúc như thế này:

Cook <=> Server <=> Customer

Bạn muốn kiểm tra từng lớp một cách độc lập. Đây Serverlà lớp dịch vụ của bạn và Cookcó thể được coi là một DAO. Các Serverlà những gì bạn muốn chế nhạo trong khi thử nghiệm Customer, và Cooklà những gì bạn muốn mô hình trong khi kiểm tra Server. Các Cookbài kiểm tra đơn vị, tuy nhiên, nên xác minh rằng việc thực hiện đang trở lại một hamburger khi một chiếc bánh hamburger được lệnh và không phải là một lốp cao su.

Hoàn toàn ổn khi kiểm tra businesslogic cùng với cơ sở dữ liệu. nhưng các kiểm tra này được gọi là kiểm tra tích hợp ngay cả khi bạn sử dụng nunit hoặc junit hoặc phpunit để thực hiện các kiểm tra này.

Unittests là các thử nghiệm spezialized trong đó thử nghiệm trong sự cô lập (ví dụ như buisinesslogic không có cơ sở dữ liệu) là quan trọng. Giả / giả / stups được sử dụng để thực thi sự cô lập này.

Một lý do khác là để tránh thời gian thực hiện chạy các lệnh cơ sở dữ liệu. Có vẻ như không nhiều nhưng chi phí thiết lập và phá vỡ các kết nối cuối cùng sẽ tăng lên và rất có thể sẽ tăng đáng kể thời gian tổng thể để chạy bộ thử nghiệm so với sử dụng các đối tượng giả.

Đơn giản là: để kiểm tra DAO thực tế và không phải nội dung cơ sở dữ liệu.

Giả sử lớp DAO Person của bạn có một phương thức getByName (). Bạn viết một bài kiểm tra và gọi Person.getByName ("John Smith"). Giả sử thử nghiệm thất bại, vì ai đó đã xóa hồ sơ của John khỏi cơ sở dữ liệu. Bây giờ, mọi phần mềm CI và người giám sát / người đánh giá của bạn có thể cho rằng phần mềm của bạn bị lỗi, trong khi thực tế thì không phải vậy. Nếu bạn giả định DB, bạn có thể chứng minh rằng DAO của bạn hoạt động nếu được cung cấp đúng hàng từ bảng chính xác.

Nếu bạn thực sự muốn kiểm tra cơ sở dữ liệu, tức là: nếu việc thực thi phương thức DAO nào đó đặt dữ liệu ở một trạng thái nhất định, thì điều đó cũng có thể. Hơn nữa, nó thực sự hữu ích với các mô hình dữ liệu lập dị (EAV, tập hợp cây lồng nhau) nơi bạn không thể mong đợi cơ sở dữ liệu cung cấp tính toàn vẹn chống đạn. Hãy nhìn vào DBUnit để làm cho cuộc sống của bạn dễ dàng hơn.

Để cô lập lớp bạn đang kiểm tra. Hoặc nếu không, kiểm tra không thành công, làm thế nào để bạn biết vấn đề nằm trong lớp bạn đang kiểm tra hoặc một trong những phụ thuộc của nó.