TDD với SQL và các hàm thao tác dữ liệu

Trong khi tôi là một lập trình viên chuyên nghiệp, tôi chưa bao giờ được đào tạo chính thức về công nghệ phần mềm. Vì tôi thường xuyên truy cập vào đây và SO, tôi đã nhận thấy xu hướng viết bài kiểm tra đơn vị bất cứ khi nào có thể và, vì phần mềm của tôi trở nên phức tạp và phức tạp hơn, tôi thấy kiểm thử tự động là một ý tưởng tốt trong việc hỗ trợ gỡ lỗi.

Tuy nhiên, hầu hết công việc của tôi liên quan đến việc viết SQL phức tạp và sau đó xử lý đầu ra theo một cách nào đó. Làm thế nào bạn sẽ viết một bài kiểm tra để đảm bảo SQL của bạn đã trả về dữ liệu chính xác, ví dụ? Sau đó, giả sử nếu dữ liệu không nằm trong tầm kiểm soát của bạn (ví dụ: hệ thống của bên thứ 3), làm thế nào bạn có thể kiểm tra hiệu quả các quy trình xử lý của mình mà không phải viết các luồng dữ liệu giả?

Giải pháp tốt nhất tôi có thể nghĩ đến là đưa ra các quan điểm về dữ liệu, cùng nhau, bao quát hầu hết các trường hợp. Sau đó, tôi có thể tham gia các khung nhìn đó với SQL của mình để xem liệu nó có trả về các bản ghi chính xác không và xử lý các khung nhìn theo cách thủ công để xem các chức năng của tôi, v.v. có đang làm những gì chúng được cho là không. Tuy nhiên, nó có vẻ quá mức và flake; đặc biệt là tìm dữ liệu để kiểm tra ...

Một quy tắc quan trọng để kiểm tra mọi thứ liên quan đến cơ sở dữ liệu là tách biệt hoàn toàn với phần còn lại của ứng dụng.

Các cổng và kiến trúc bộ điều hợp là một ví dụ thực sự tốt. Cơ sở dữ liệu được coi là một plugin bên ngoài thông qua một bộ chuyển đổi cho ứng dụng của bạn. Điều tương tự cũng xảy ra với tất cả các hệ thống con của bên thứ 3. Để kiểm tra xem ứng dụng của bạn sẽ hoạt động như thế nào và diễn giải các phản hồi của các hệ thống con bên thứ 3 theo cách duy nhất tôi biết cách kiểm tra đó là để loại bỏ các phản hồi của hệ thống con riêng lẻ này. Tôi không nhất thiết có nghĩa là bạn sẽ phải tự viết tất cả các đối tượng dữ liệu. Bạn có thể dễ dàng thực hiện phương pháp sử dụng thử nghiệm dựa trên dữ liệu.

Liên quan đến việc kiểm tra cách ứng dụng của bạn tương tác với cơ sở dữ liệu của bạn, bạn có thể giả mạo các bộ điều hợp cơ sở dữ liệu để sử dụng cơ sở dữ liệu trong bộ nhớ chẳng hạn.

Bây giờ kiểm tra truy vấn cơ sở dữ liệu của bạn. Trước hết, các truy vấn phức tạp nên được phân tách thành các truy vấn dễ dàng, đơn giản và dễ đoán hơn. Điều tương tự bạn sẽ làm cho một lớp chất béo hoặc cho một chức năng chất béo. Có những công cụ có thể giúp bạn kiểm tra cơ sở dữ liệu của mình như Dbunit. Một cách tiếp cận đơn giản đôi khi tôi thực hiện là sử dụng khái niệm kiểm tra đặc tính. Vì vậy, tôi sẽ đặt cơ sở dữ liệu ở trạng thái biết, chạy tất cả các truy vấn tôi phải ghi lưu đầu ra vào một vị trí (tệp, bộ nhớ) và coi đầu ra này là chính xác. Các lần chạy tiếp theo sẽ so sánh đầu ra của chúng với cái này, vì vậy nó chắc chắn sẽ cung cấp cho tôi thử nghiệm hồi quy tôi cần. Thật vậy, đầu ra đầu tiên không được đảm bảo là đúng nhưng vấn đề hồi quy có thể được giải quyết theo cách này. Nếu các truy vấn của bạn được phân tách tốt, bạn có thể kiểm tra chúng riêng lẻ đối với cơ sở dữ liệu ở trạng thái đã biết.

Đó là một câu hỏi thú vị bởi vì cơ sở dữ liệu thường là phần bị làm giả trong quá trình kiểm tra đơn vị ứng dụng. Hy vọng rằng logic của chính công cụ cơ sở dữ liệu đã được nhà cung cấp kiểm tra tốt nhưng tất nhiên các truy vấn, lược đồ và các thủ tục được lưu trữ là mã cần được kiểm tra và bảo vệ chống lại hồi quy. Điều này thường được để lại cho thử nghiệm tích hợp không phải là TDD.

Lượt xem có thể là một cách khó thực hiện vì chúng không thực sự cho phép thử nghiệm thử nghiệm tự động đèn đỏ, đèn xanh đầu tiên về một khía cạnh cho mỗi thử nghiệm được ưa thích trong TDD. Ngoài ra với các lượt xem, bạn không thể viết bài kiểm tra trước khi viết mã. Một cách tiếp cận tốt hơn sẽ là viết các thủ tục được lưu trữ trong đó bạn có thể thêm logic "khẳng định" trong thủ tục (ví dụ: sử dụng các câu lệnh "if") để kiểm tra lỗi đầu ra. Bạn chỉ cần kiểm tra một điều trong mỗi bài kiểm tra đơn vị để cô lập đơn vị, và phương pháp SP sẽ phù hợp hơn cho điều đó. Ngoài ra, với SP, bạn có thể chạy toàn bộ bộ phần mềm dưới dạng tập lệnh khi bạn phát triển mã ban đầu và sau này khi kiểm tra hồi quy khi tái cấu trúc.

Ngoài ra, hãy lưu ý rằng các bài kiểm tra phải được lặp lại và bạn sẽ cần một số tập lệnh để khởi tạo và phá bỏ trạng thái cơ sở dữ liệu để đảm bảo rằng trạng thái giống nhau cho mỗi bài kiểm tra đơn vị.

Đối với câu hỏi của bạn về dữ liệu không thuộc quyền kiểm soát của bạn, đó là một lĩnh vực khó khăn. Tôi nghĩ rằng tốt hơn hết là bạn nên chế nhạo nó bằng dữ liệu giả và kiểm tra các điều kiện ngoại lệ và cạnh càng nhiều càng tốt cho các bài kiểm tra đơn vị. Nếu không, nó sẽ rơi vào danh mục kiểm thử tích hợp (đó cũng là một việc nên làm). Để kiểm tra tích hợp, bạn có thể chạy thử nghiệm đối với dữ liệu của bên thứ 3 và để nó tạo đầu ra ban đầu và cho các thử nghiệm tiếp theo (ví dụ: sau khi tái cấu trúc), đảm bảo các đầu ra đó lặp lại đầu ra đã biết ban đầu.

Tại một số điểm bạn sẽ cần dữ liệu thử nghiệm. Nếu bạn đang sử dụng hệ thống của bên thứ 3, lược đồ đã được tạo, nhưng bạn sẽ cần giải quyết các thay đổi trong tương lai. Hy vọng, bạn có thể nhận được những thay đổi này từ tài liệu nâng cấp, nhưng bạn có thể buộc phải tự so sánh các phiên bản cơ sở dữ liệu.

Các tập kết quả dự kiến ​​có thể được lưu trong các bảng cơ sở dữ liệu hoặc các tệp / bảng tính bên ngoài. Tôi thậm chí đã thấy CHECKSUM được sử dụng hoặc so sánh. Khi bạn kiểm tra chế độ xem / sproc, bạn sẽ gặp thất bại vì chúng không tồn tại. Sau đó, bạn tạo đối tượng có đủ mã ít nhất để thực thi (CHỌN -1 là [false_data];) và bạn sẽ gặp lỗi vì nó không khớp với tập kết quả. Một khi chúng phù hợp, bạn có đèn xanh của bạn.

Tôi đã bắt đầu làm việc với chủ dự án và yêu cầu họ giả lập báo cáo trong bảng tính và cố gắng đưa ra dữ liệu một phần cho tôi (Bạn có thể đặt dữ liệu kết quả vào bảng thử nghiệm.). Lúc đầu có một số phản hồi, nhưng họ nhận ra rằng tôi sẽ tạo một báo cáo và dù sao họ cũng sẽ phải xác minh nó. Điều này đã tiết kiệm thời gian trong thời gian dài. Nếu họ muốn thực hiện một yêu cầu thay đổi, họ có thể làm lại bảng tính. Bây giờ họ có thể trả lời câu hỏi, "Làm thế nào khó hơn để thêm ...?"

Nếu nền tảng cơ sở dữ liệu của bạn là SQL Server, có một công cụ miễn phí rất hay: tQueryt .

tQueryt là một khung kiểm tra đơn vị cơ sở dữ liệu cho Microsoft SQL Server. tQueryt tương thích với SQL Server 2005 (yêu cầu gói dịch vụ 2) trở lên trên tất cả các phiên bản.

Tôi đã sử dụng thành công để thực hiện thử nghiệm ở cấp cơ sở dữ liệu.

Một số yếu tố chính làm cho nó rất hữu ích bao gồm:

• Khả năng làm việc với các bảng và khung nhìn giả làm giảm thiết lập thông thường liên quan
• Kiểm tra tự động chạy trong các giao dịch (vì vậy dễ dàng chạy lại)
• Xác nhận của bạn có thể so sánh trên các bảng (cả thật và giả) để bạn có thể xem liệu bạn có thay đổi bất kỳ dữ liệu nào một cách dễ dàng không