كيفية اختبار وحدة اختبار عميل WCF مصنوع من طقم Starter WCF

Question

لقد قمت بإنشاء بعض خدمات POX باستخدام مجموعة Starter REST. في البداية ، كان من المعقد بعض الشيء إنشاء اختبارات الوحدة لطبقة الخدمة ، ولكن في النهاية ، تم تصميمها جيدًا وأنجحت في السخرية من السياق وتحديد التوقعات.

لكنني أبدأ الآن مع جانب العميل ، وأواجه بعض المشكلات في معرفة كيفية السخرية من الأشياء. إنه ليس مستقيمًا للأمام.

لذلك ، لدي طريقة نموذجية تنشر عبر HTTP بعض البيانات باستخدام DataContract و XML كنقل.

public class ServiceClient: IService

{
    private const string uri_template = "http://{0}:{1}/SomeService.svc/";
    private readonly HttpClient http = new HttpClient();

    public ServiceClient(string host, int port)
    {
        http.BaseAddress = new Uri(string.Format(uri_template , host, port));
    }

    public void Create(MyDataContract my_data_contract)
    {
        var content = HttpContentExtensions
                        .CreateDataContract(
                          my_data_contract, 
                          Encoding.Default, 
                          "text/xml", 
                          null);
        var response = http.Post("Create", content);
        if (response.StatusCode != HttpStatusCode.Created) {
            throw new Exception("something is not right");
        }
    }
}

هذه الطريقة تعمل وتنشر البيانات والتسلسل بشكل صحيح.

ما أريد أن أفعله ، هو اختبار الوحدة.

أسئلتي هي:

1. كيف أقوم بعمل كعب/نخيل لـ httpcontextextensions مع العلم أنه لا ينفذ أي واجهة؟

2. و HTTPClient؟ هذا هو الأسوأ لأنه مليء بطرق التمديد المحددة في مكان آخر (النشر والطرق المتشابهة هي امتدادات).

في 2. أعتقد أنني أستطيع التمسك بـ "إرسال" و Adloves ، ولكن بعد ذلك هي المشكلة نفسها كما في 1

ما كنت أفكر في القيام به ، هو استخراج واجهات HTTPContexTextensions و HTTPClient ، وجعل الأطفال لكل واحد وتنفيذ الواجهات التي تنفصل إلى الوالد ، ثم استخدام الواجهات في الكود الخاص بي.

لكن هذا كثير من العمل IMHO.

أنا أستخدم الأنف من إطار العمل الساخط الخاص بي ، لذا لا يمكنني السخرية من الفصول الخرسانية/كذبة ، وأود أن ألتزم بها ، لأنني أعتقد حقًا أن السخرية من الفصول الخرسانية ليست أنيقة للغاية.

لذلك ، هل هناك طريقة أنظف/أسرع/أكثر ذكاءً إلى رمز اختبار الوحدة مثل ما سبق؟

PD: هذا هو لـ WCF Starter Kit Preview 2

Answer 1

إذا كنت ترغب حقًا في السخرية من هذا الرمز ، فإن النهج الذي يمكن أن ينجح في هذا السيناريو هو تلقي مثيل HTTPClient في فئة ServiceClient. تحتوي فئة HTTPCLIENT على خط أنابيب معالجة يمكنك تخصيصه باستخدام معالجات مخصصة. بالنسبة للاختبارات الخاصة بك ، يمكنك في الأساس حقن معالج في مثيل HTTPCLIENT لإرجاع استجابة مفعمة بالآمال إلى الاختبار قبل أن يتم استدعاء الخدمة الحقيقية في المعالج الأخير (مرحلة النقل). ألقِ نظرة على هذا المنشور للحصول على فكرة عن كيفية تنفيذ ذلك ،

http://weblogs.asp.net/cibrax/archive/2009/03/18/negotiating-a-saml-token-for-rest-clients-httpclient.aspx

التحيات ، بابلو.

Answer 2

كتبت معظم رمز httpclient. اقتراح بابلو هو ما قمت به في اختبارات الوحدة - راجع lextransport.cs في ZIP المصدر.