Thử nghiệm tích hợp "Nhanh" của Dịch vụ WCF

Question

Bối cảnh

Tôi là một fan hâm mộ lớn về những gì Roy Osherove gọi là "Kiểm tra tích hợp nhanh". Đây là thử nghiệm tích hợp:

• Được thực hiện nghiêm túc trên hộp phát triển của bạn. Không cần một môi trường riêng biệt.
• Mặc dù là thử nghiệm tích hợp, các thử nghiệm như vậy thường được khởi chạy từ công cụ kiểm tra đơn vị của bạn (NUnit, MsTest, v.v.)
• Thường chạy trong bộ nhớ: một quá trình thực thi.
• Chạy nhanh. Không nên có giây kéo dài triển khai tiếp theo giây kéo dài khởi động đóng đai vv
• Phải kiểm soát nguồn thân thiện:
  • các nhà phát triển khác sẽ có thể chỉ đơn giản là để kéo nguồn và chạy thử nghiệm hội nhập nhanh, mà không cần phải chống lại các vấn đề về cấu hình (ví dụ như thiết lập các thư mục ảo IIS, v.v.)
  • Bất cứ khi nào có thể, nó phải tương thích với các thử nghiệm tự động tích hợp liên tục (CI).

Vấn đề

Cho một giải pháp VS 2010 với một số dịch vụ WCF được tích hợp thử nghiệm, tôi đã nghiên cứu cách thức tốt nhất để đi về việc này. Các yêu cầu khác của tôi về thiết lập thử nghiệm là:

• Dịch vụ WCF được lồng nhau. Nghĩa là, một dịch vụ có thể gọi một dịch vụ khác trong quá trình kiểm tra tích hợp nhanh.
• Ngăn xếp WCF phải đầy đủ hoặc chủ yếu hoạt động.
  • Gọi trực tiếp điểm nhập hợp đồng dịch vụ có thể là ok để kiểm tra đơn vị, nhưng không phải cho thử nghiệm tích hợp này.
  • REST và BasicHttp bindings sẽ hoạt động và tốt nhất là wsHttpBinding.
• Web.config
  • Các web.config transform (XDT) của từng dự án WCF nên đi vào hoạt động, mặc dù triển khai có thể hoặc không thể xảy ra để đạt được thử nghiệm này.
  • Công cụ kiểm tra đơn vị, chẳng hạn như MsTest hoặc NUnit, nên không yêu cầu web.config hợp nhất đại diện cho tất cả các dịch vụ sẽ được lưu trữ trong khi thử nghiệm.
• Dịch vụ lưu trữ WCF có thể là 32 bit hoặc 64 bit.
• Các WCF dịch vụ lưu trữ có thể là một trong hai trong bộ nhớ với các công cụ kiểm tra đơn vị, hoặc out-of-quá trình thông qua host như Cassini, IIS Express, vv
  • Tôi chắc chắn nghiêng về phía một trong- tiếp cận bộ nhớ, bởi vì nó đơn giản hóa các vấn đề đồng bộ hóa thử nghiệm. Nói cách khác, một số dịch vụ WCF của tôi thực thi không đồng bộ và được hoàn thành sau phản hồi WCF đã được gửi đến lịch thi đấu văn bản.Với cách tiếp cận trong bộ nhớ, tôi có thể thực hiện thử nghiệm Monitor.Wait để đảm bảo công việc không đồng bộ được hoàn thành trước khi thoát khỏi thử nghiệm. Đối với lưu trữ và thử nghiệm đa quy trình, tôi có thể phải dựa vào hệ thống tệp và các sự kiện hệ thống tệp để đạt được cùng một đồng bộ hóa.

Trả lời?

Tôi muốn liệt kê các phát hiện của mình cho đến nay và hỏi công cụ (s) hoặc kỹ thuật nào tôi đang thiếu. Một lần nữa, câu hỏi này liên quan đến Visual Studio 2010, mặc dù nhận xét bổ sung về năm 2012 được hoan nghênh.

Đối với các giải pháp trong bộ nhớ, có vẻ như có hai lựa chọn cơ bản. Hoặc sử dụng một phiên bản custom ServiceHost cho từng dịch vụ hoặc sử dụng một trong số variety of other self-hosting tools. Trong liên kết thứ hai, câu hỏi ban đầu là về sản xuất lưu trữ - nhưng hầu hết các công cụ được liệt kê có khả năng tự lưu trữ hoặc trong bộ nhớ.

Tác giả của CassiniDev, được đề cập trong liên kết thứ hai ở trên, đề xuất CassiniDev được sử dụng khi kiểm tra vòng lặp (localhost) không đủ. Trong trường hợp của tôi, tôi nghi ngờ kiểm tra loopback là tốt. Tác giả đó gợi ý rằng khi thử nghiệm lặp lại là ok, thì một câu chuyện nhẹ hơn là sử dụng WebDevServer code của mình. Nếu tôi hiểu chính xác, mã WebDevServer thực sự là mã Visual Studio nội bộ mà anh ta đã phản ánh và sửa đổi cho mục đích tự lưu trữ thử nghiệm.

Đối với các giải pháp trên hộp (đa quy trình), tôi thấy có cách để tạo Cassini fit the 64 bit requirement. Nếu không, đối với IIS Express hoặc IIS, tôi không chắc chắn về các vấn đề về khả năng cấu hình của nhà phát triển đến nhà phát triển. Thông thường khi một nhà phát triển cấu hình IIS Express hoặc IIS trên một máy cụ thể, thường thì các nhà phát triển khác sẽ không có thông tin cấu hình đó và đang cố gắng thực hiện công việc kiểm tra trên hộp của riêng họ. Tôi đã thấy các nhà phát triển sản xuất các kịch bản sử dụng appcmd.exe để tự động cấu hình như vậy, nhưng tất cả các tập lệnh quá thường xuyên được duy trì kém. Tôi muốn tránh tình huống đó.

Trong cả hai trường hợp, tôi tin (các) tùy chọn của tôi cho automating the web.config transform (XDT), without a deploy, is discussed here.

Ok, chiến lược và chiến thuật tốt hơn là gì? Tôi muốn biết ...

Answer 1

Điều này không trả lời câu hỏi về thử nghiệm tích hợp nhanh như người hỏi yêu cầu, nhưng liên kết bên dưới là hướng dẫn toàn diện nhất về cách làm cho WCF có thể kiểm chứng.

https://codereview.stackexchange.com/questions/33379/make-wcf-service-testable?newreg=016e2809b68248958ff3c45973efe643

Tuy nhiên, tôi không thể xác minh cho bao xa hướng dẫn này sẽ đưa bạn về việc phát triển các xét nghiệm cho ngăn xếp đầy đủ các chức năng WCF.