2009-06-07 35 views
5

Tôi có nhiều đối tượng với các phương thức yêu cầu quyền truy cập cơ sở dữ liệu. Chúng tôi đang tìm kiếm để có được vào thử nghiệm đơn vị nhưng rất quan tâm để tránh việc sử dụng các đối tượng giả nếu có thể. Tôi tự hỏi nếu có một cách để cấu trúc lại phương thức Validate được hiển thị bên dưới để nó không cần truy cập db. Trong ứng dụng thực tế thường có một chút công bằng hơn nhưng tôi nghĩ rằng ví dụ đơn giản này là đủ.Tránh phụ thuộc cơ sở dữ liệu để kiểm tra đơn vị mà không bị nhái

Chúng tôi sẽ học cách sử dụng các đối tượng mô phỏng nếu cần nhưng có vẻ như rất nhiều chi phí, vì vậy tôi đang tìm kiếm các giải pháp thay thế.

public class Person 
    { 
     public string Name; 

     public string Validate() 
     { 
      if (PersonDA.NameExists(Name)) 
      { 
       return "Name Already Used"; 
      } 

     } 
    } 
+2

Đảm bảo bạn biết sự khác biệt giữa "kiểm tra đơn vị" và "thử nghiệm tích hợp" và thời điểm sử dụng chúng và những gì chúng phù hợp nhất. –

+0

Đôi khi tôi sử dụng mẫu sau không yêu cầu khung mocking http://www.unit-testing.net/CurrentArticle/How-To-Remove-Data-Dependencies-In-Unit-Tests.html – T123

Trả lời

7

Cá nhân tôi chỉ cần đi theo tuyến đối tượng giả. Nó linh hoạt hơn nhiều và có vẻ như bạn muốn đi con đường đưa mã thử nghiệm vào đối tượng thực sự của bạn?

Không có gì, trích xuất mã xác nhận thành đối tượng PersonValidator với phương thức cho boolean isValid (Person). Sau đó, trong mã thử nghiệm, sử dụng trình xác thực mô phỏng chỉ trả về true hoặc false dựa trên trường hợp kiểm tra.

+0

không muốn đặt mã thử nghiệm vào đối tượng. Chỉ cần tự hỏi nếu có một số cách tái cấu trúc, tôi đã không nghĩ rằng sẽ loại bỏ sự cần thiết cho các đối tượng giả. – tjjjohnson

0

Bạn chỉ nên thiết lập cơ sở dữ liệu được sử dụng cho thử nghiệm đơn vị. Nếu bạn sử dụng mockups cho tất cả các truy cập dữ liệu, bạn sẽ không thực sự được thử nghiệm nhiều? :)

+0

có lẽ tôi đã đơn giản hóa ví dụ. Thường thì sẽ có thêm kiểm tra được tiến hành để thực hiện một việc khác ngoài việc chỉ gọi phương thức truy cập dữ liệu. – tjjjohnson

+0

Không đồng ý - trong khi kiểm tra-db là một công cụ có giá trị để có trong khuôn khổ thử nghiệm của bạn, bạn nên tích cực cố gắng giảm thiểu việc sử dụng nó trừ khi cần thiết. Một cái gì đó như xác nhận một tên chưa được nhìn thấy trước đây không có nhu cầu nội tại để nhấn một cơ sở dữ liệu - đó là một chi tiết thực hiện - và như vậy nên được kiểm tra mà không có sự phụ thuộc đó nếu có thể. – dimo414

2

Hãy xem dbunit, thiết lập đặc biệt để tạo cơ sở dữ liệu thử nghiệm nhỏ để bạn có thể sử dụng các đối tượng thực của mình trên cơ sở dữ liệu giả trong khi kiểm tra đơn vị. Việc thử nghiệm với nó dễ dàng hơn nhiều so với việc phát triển các đối tượng giả, an toàn hơn nhiều so với việc sửa đổi mã truy cập dữ liệu của bạn, và sâu sắc hơn nhiều so với cả hai.

+0

Nó cũng cho phép bạn chắc chắn rằng mã thực sự hoạt động, không chỉ thông qua các đối tượng giả lập (đơn giản hơn). –

5

Lớp người khó kiểm tra đơn vị vì lớp này có phụ thuộc tĩnh, ẩn trên mã truy cập cơ sở dữ liệu. Bạn có thể phá vỡ sự ghép nối này bằng cách giới thiệu một sự cộng tác năng động giữa Person và một số kiểu đối tượng mới cung cấp nó với thông tin cần thiết để xác nhận trạng thái của nó. Trong các bài kiểm tra đơn vị của bạn của Person, bạn có thể kiểm tra những gì xảy ra khi nó hợp lệ hoặc không hợp lệ mà không cần nhấn vào cơ sở dữ liệu bằng cách chuyển đối tượng Person "stub" triển khai của cộng tác viên của nó.

Bạn có thể kiểm tra triển khai thực sự, truy cập cơ sở dữ liệu, trong một bộ kiểm tra riêng biệt. Những bài kiểm tra sẽ chậm hơn nhưng sẽ có ít hơn vì chúng sẽ được dịch trực tiếp các phương thức truy cập vào các truy vấn cơ sở dữ liệu mà không có logic phức tạp của riêng chúng. Bạn có thể gọi đó là "sử dụng các đối tượng giả" nếu bạn thích nhưng, vì thiết kế hiện tại của bạn có nghĩa là bạn chỉ cần truy vấn, không mong đợi các lệnh, một khung đối tượng giả là một công cụ quá phức tạp cho công việc. Cuống viết tay sẽ làm cho các lỗi kiểm tra dễ chẩn đoán hơn.

+0

+1 - Kiểm tra đơn vị là tất cả về các phụ thuộc và quản lý chúng. – duffymo

0

Tại sao bạn cố tránh chính xác mocks? Nếu bạn đang đi để thực hành thử nghiệm đơn vị và bạn có mã truy cập dữ liệu, nó sẽ được dễ dàng nhất để có được thoải mái với mock/stub/tiêm cách làm việc.

Nếu đó là vì bạn không muốn đưa vào một khung mocking, bạn có thể mã lên một số cuống đơn giản khi bạn cần chúng.

Việc đặt mã truy cập dữ liệu của bạn phía sau giao diện sẽ cho phép tránh nhu cầu cơ sở dữ liệu. Xem xét sử dụng tiêm phụ thuộc để chèn mã truy cập dữ liệu giả hoặc sơ khai trong các thử nghiệm của bạn.

+0

chủ yếu chỉ cố gắng tìm ra nếu có lựa chọn thay thế để chế giễu cho tình huống này. – tjjjohnson

Các vấn đề liên quan