Sinon: الإصدار 2.0 خلاف ذلك

أرغب في إنشاء موقع ويب جديد للوثائق ، بناءً على العمل الموجود بالفعل في /docs . آمل أن أقضي بعض الساعات في ذلك خلال إجازتي الأسبوع المقبل.

mroderick إذا تم دفع العمل في مكان ما ، فأخبرني بذلك. قد أكون قادرًا على المساعدة في المستندات!

تم تحديث مربعات الاختيار. لست متأكدًا مما إذا كان يجب تحديد "Migrate sinon.sandbox" ، ولكن على الأقل يتم إغلاق PR.

jonnyreeves : لست متأكدًا من سبب إزالة sinon.test . هذا هو وضع الحماية حول الاختبار الذي ينظف أي بذرة يتم إنشاؤها وتجسسها تلقائيًا بعد الاختبار. هذا يريح الناس من الكثير من وظائف beforeEach و afterEach . مفيد جدًا ، ولا علاقة له باختبار الأطر.

سيحتاج المستخدمون إلى رؤية بديل سهل لهذا حتى تتم إزالته لصالح شيء آخر (أفضل).

لم أستخدم أبدًا sinon.testCase بنفسي ، ربما لأن واجهته تناسب BusterJS (حيث تكون كل حالة اختبار من خصائص مجموعة الاختبار) وليس Mocha (حيث يكون كل اختبار عبارة عن وظيفة مجهولة تعمل في جسم مجموعة الاختبار ).

@ fatso83 المشكلة الرئيسية لدي مع sinon.test هي حقيقة أنه يعتمد على sinon.config الفردي. يمكن لمستخدمي IMHO الحصول على قدر أكبر من التحكم عن طريق إنشاء (واستعادة) وضع الحماية في خطافات beofreEach و afterEach في إطار الاختبار الخاص بهم.

إذا كنا سنحتفظ بـ sinon.test (و sinon.testCase ) في واجهة برمجة التطبيقات العامة ؛ ثم نحتاج إلى معالجة كلتا هاتين المسألتين - على الرغم من أنني مستخدم / دعم لوقت طويل لـ sinon ، فأنا جديد في اختراق مشروعه - كيف يجب أن نصل إلى الحل؟

jonnyreeves حسنًا ، كان من المنطقي أكثر عندما ذكرت أنها تعتمد على sinon.config . يعد إنشاء IMHO واستعادتها بشكل صريح أمرًا جيدًا طالما أننا نوفر هذا كبديل للأشخاص القادمين من Sinon 1 ويتساءلون عما حدث لـ sinon.test . لذلك يجب أن تقرأ الدومينيشن شيئًا مثل

sinon.test

_ تم إهمال هذا في الإصدار 2 لصالح إنشاء وضع الحماية بشكل صريح. انظر link to sandbox ._

أنا مشترك في واجهة برمجة تطبيقات أصغر حجمًا في الإصدار 2 ، لذلك يمكن تقديم أشياء مثل typeOf ، extends و sinon.test* بشكل أفضل من خلال وحدات NPM الأخرى أو وظائف أخرى موجودة.

أعتقد أن شيئًا مثل npm install sinon-test و var sinonTest = require('sinon-test')(config); يمكن أن يكون بديلاً لائقًا.

: +1: لنقل المرافق مثل هذه إلى وحدات npm منفصلة. رمز أقل في core

شكرا على الادخال؛ لقد قمت بتحديث النظرة العامة لأعلى لتعكس المناقشة حتى الآن (بشكل أساسي إزالة علامات الاستفهام ، وجعل المهام أكثر وضوحًا) ، يرجى إلقاء نظرة.

أيضًا ، هل يمكننا الحصول على إغلاق مماثل في:

• إزالة sinon.log و sinon.logError (كلاهما مستخدَم من قبل fake_server ؛ وربما من الأفضل تمريرهما كتكوين لتلك الحالات)
• إزالة sinon.mock من 2.0

شكرا

لم أستخدم أبدًا sinon.testCase ، ومع ذلك فأنا مستخدم كثيف لـ sinon.test . أنا بخير مع الذهاب إلى مكتبة منفصلة ، ولكن فقط لا تنسى: هناك عدد غير قليل من الأشخاص الذين يستخدمون أطر اختبار لا تدعم beforeEach حسب التصميم (مثل الشريط) مع الحجة القائلة بأن هذه الإعدادات تؤدي الوظائف إلى حالات اختبار مقترنة. قد نتسبب في الكثير من المشاكل لهؤلاء المستخدمين إذا لم يكن هناك بديل بسيط.

أعتقد أنه يمكننا تقديم شيء مثل هذا كمسار للهجرة:

sinon.test = require('sinon-test');

@ مانتوني : اقتراح رائع. بمجرد التعيين إلى الخاصية test غير المستخدمة الآن ، فإنها تمنح الأشخاص أقل قدر من المتاعب من خلال تضمين سطر إضافي واحد فقط في اختباراتهم. علينا فقط التأكد من عدم تجميد الكائن sinon (كما في Object.freeze(sinon) ) في مرحلة ما ...

jonnyreeves : بخصوص sinon.mock أتذكر أن mroderick اقترح الانتظار حتى إصدار 2.0 قبل إزالة هذا. لقد أشرنا بالفعل لبعض الوقت إلى أنه قد تم إهماله ، لذلك يجب أن يكون جيدًا لإزالته بعد الإصدار 2.0 من IMHO. ولكن نظرًا لأن لدينا بالفعل دعم CommonJS ، فلن أمانع في إزالته قبل الإصدار 2.0 _if_ لقد استخرجنا الكود إلى وحدة نمطية خاصة به. ثم يمكن للناس فقط let sinon.mock = require('sinon-mock') ، إذا كانوا سعداء.

بالنسبة إلى sinon.log* ، لا أرى أي سبب للتشبث بها كميزات عامة إذا كان بإمكاننا توفيرها كتكوين عند الحاجة.

WRT باقتطاع sinon-test ، لاحظ فقط أننا سنحتاج إلى السماح للمستهلكين بتوفير تكوين ، على سبيل المثال:

sinon.test = require('sinon-test').withConfig({ ... });

أو مشابه.

اكتشفت للتو تغييرًا محتملاً آخر لواجهة برمجة التطبيقات أثناء إنشاء حزمة sinon-test ؛ أي أفكار حول ما يجب أن يحدث لـ sinon.assert ؟ مرة أخرى ، هذا لا يبدو أنه جزء أساسي من واجهة برمجة تطبيقات sinon بالنسبة لي وقد يكون مناسبًا بشكل أفضل من خلال الانتقال إلى حزمة sinon-test بجانب sinon.test و sinon.testCase ؟

@ fatso83mantonicjohansen. لديّ إصدار عملي لحزمة sinon-test جاهزة للمراجعة - هل يمكن لأحدكم أن يهيئ مستودع git فارغًا عند sinonjs/sinon-test حتى يمكنني رفع PR مقابله من فضلك؟

شكرا

ذلك كان سريعا! https://github.com/sinonjs/sinon-test

cjohansen ، هل يمكنك فقط دفع رسالة README فارغة إليها من فضلك؟ يبدو أنني لا أستطيع رفع العلاقات العامة في الوضع الحالي.

منتهي

شكرًا ، تم رفع العلاقات العامة - نرحب بالتعليقات: https://github.com/sinonjs/sinon-test/pull/1

mroderick إذا تم دفع العمل في مكان ما ، فأخبرني بذلك. قد أكون قادرًا على المساعدة في المستندات!

تضمين التغريدة لقد قمت بإنشاء # 991 لتتبع هذا بشكل منفصل عن بقية الجهد. سأقوم بتحديث هذا في الأيام القادمة بأفكاري ، ويمكننا أخذها من هناك.

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

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

قد يعني ذلك أيضًا عبء الإدارة المتمثل في إبقاء هذا المستودع متزامنًا مع أدوات التطوير ، وما إلى ذلك.
ربما يجب أن نتأكد من إعداد أدوات تطوير مشتركة سهلة أولاً؟ سم مكعب: @ مانتوني

mroderick @ fatso83 حسنًا ، دعنا نرى ما إذا كان بإمكاننا إخراج 2.0 من الباب.

لقد قمت بتحديث النظرة العامة على هذا العدد لتغطية ما أعتبره جميع عمليات الترحيل المعلقة (بما في ذلك CJSification of the testuite ، من فضلك ، إذا كنت تقرأ هذا - مساعدة!) - يرجى إلقاء نظرة وإعلامي إذا كنت توافق على العمل المتميز.

بالإضافة إلى ذلك ، أود الحصول على إجماع على ما يلي:

1. هل يجب إزالة typeOf و extend من واجهة برمجة التطبيقات العامة ( sinon. ) ، أو يجب انتظار Sinon 3.x الذي (أفترض) سيخضع لتحديث API .
2. هل يجب إزالة دعم IE القديم / الاختراقات من الإصدار 2.0؟ هذا _may_ يبسط الترحيل حيث يمكننا إسقاط رمز "fakeXDM" - لم ألق نظرة عن كثب لذلك لا يمكنني تقدير هذا العمل حقًا حتى الآن.
3. هل يعد شحن موقع المستندات الجديد شرطًا أساسيًا لإصدار 2.0؟ أشعر بالقلق لأنه ليس لديه الكثير من الجر :)

شكرا لكم جميعا.

@ jonnyreeves : لقد كنت بالتأكيد نحلة مشغولة الليلة 😺. أمامي إجازة طويلة ، لذا يمكنني بالتأكيد المساعدة في عمليات الترحيل المعلقة لمجموعة الاختبار (هناك علامة "لكن" أدناه).

بخصوص نقاطك:

1. يجب أن يذهبوا. اعتقدت أن هذا قد تم تسويته إلى حد كبير (المرجع ، النظرة العامة أعلاه).
2. دعنا فقط نحدد "إرث IE" أولاً. الإصدارات <10 ، أو الحزمة sinon-ie بأكملها؟ كان IE9 لا يزال يشحن مع بعض البدائل الغريبة لـ CORS والتي تسمى XDR. إذا كان هناك أي شخص لا يزال يهدف إلى دعم إصدارات IE التي تم إصدارها قبل عام 2012 ، فيمكنه دائمًا استخدام فرع 1.x ، على ما أعتقد. ألست متأكدًا مما تشير إليه XDM؟ لست متأكدًا من إصدار المتصفح sinon-ie المطلوب ، لذلك لا يمكنني أن أكون منمقًا جدًا بشأن عدم الحاجة إلى الحزمة. يجب أن نكون متأكدين من العواقب.
3. التوثيق _ هو نقطة ألم في الوقت الحالي ، لكني لست متأكدًا بعض الشيء مما سأقوله هنا. يمكنني البدء في البحث في # 991 قبل المساعدة في النقاط الأخرى أعلاه. وجود مكان ما لدفع المستندات سيجعل الحياة أفضل.

فضولي ما هو الوضع على هذا؟ لا يبدو أنه قد تم إحراز تقدم كبير منذ 6 أشهر تقريبًا ؛ أنا أعتمد حاليًا على الإصدار المسبق لأسباب مختلفة (دعم Symbol الذي يعمل بشكل كبير) - لا أقصد الدفع ، ولكن هناك أمر بسيطالجدول الزمني "/" لا يوجد جدول زمني حتى الآن "سيكون رائعًا! <3

ELLIOTTCABLE لأنه ليس لدينا تمويل ، لا يوجد جدول زمني محدد. إنه يتقدم لأننا في مجموعة المشرفين - أو متطوعين آخرين مثلك - لدينا وقت للعمل على القائمة أعلاه. بعد قولي هذا ، أعتقد أنه كان من الممكن أن تجيب على "الحالة" بنفسك إذا كنت تزعج نفسك أكثر قليلاً:

1. على الرغم من أنك ترى "... تمت الإشارة إليه في 8 يوليو 2016" أعلاه ، فإن هذا يعني فقط أن التعليق الأول في القائمة من ذلك التاريخ. أشار العدد الأخير ، رقم 1235 ، إلى هذا "منذ 12 يومًا".
2. قائمة القضايا شبه كاملة - على عكس نصف عام مضى.

لذلك ... لقد وصلنا إلى مكان ما ، لكن الإشراف على إصلاحات الأخطاء للإصدار السابق ، بالإضافة إلى الإمداد المستمر بالميزات الجديدة ، يستهلك الكثير من وقت الصيانة لدينا. مجرد البحث والكتابة عن هذا استغرق نصف ساعة في النهاية 😅

في الأساس ، بعد الاطلاع على القائمة أعلاه ، هناك مشكلتان رئيسيتان فقط:

• "ترحيل خادم fake_server والأصدقاء" (تم حل 90٪ منه ، ولم يتبق سوى القليل - انظر أعلاه).
• انشر الموقع (انظر # 1220: شيء واحد بسيط وسهل للغاية ومهمة متوسطة واحدة جاهزة للاستيلاء عليها)

أعتقد أن معظم علامات الاختيار الأخرى التي تم إلغاء قفلها أعلاه تتعلق بإصدارات IE القديمة (6-10) والتي أنا متأكد تمامًا من أنها لن يتم دعمها ، بناءً على المناقشات في # 1221 ، لذا يمكن تجاهلها. سوف نتناول ذلك الآن.

@ sinonjs / sinon-core: التعليق السابق جعلني أدرك أن لدينا بعض القضايا المذكورة أعلاه والتي من غير المحتمل أن نكملها بناءً على المناقشة في # 1221:

1. هل تريد إزالة دعم IE القديم / الحلول البديلة؟
2. تحديد xdomain

أهتم إذا قمت بإنشاء علاقات عامة لإزالة بتات IE القديمة إذا لم نلمسها بأي طريقة؟ أفترض أن xdomain يمكن أن ينتهي به الأمر في أرض الملء التاريخية أيضًا ، حيث كان هذا في الغالب اختراقًا لـ IE فقط على حد سواء CORS ، لذا يمكن إزالته؟

@ fatso83 Ahhhh، k. فاتني التعليقات المحدثة على المشكلات المشار إليها. آمل أن تكون مراجعة هذا بالنسبة لي مفيدة لك!

بشكل غير مرتبط: يبدو أن جزءًا من هذا هو التخلي عن دعم IE6. هذا مؤسف. آه حسنًا ، c'est la marche du progrès! / =

نحن في الأساس هناك ، موقع المستندات لديه مشكلته الخاصة.

مرحبًا يا شباب - أي شيء يمنعنا من وضع علامة على الإصدار 2.0 باعتباره الإصدار "المستقر" للسينون وقتل 1.x؟ :)

أعتقد أننا أردنا # 1297 في آخر شيء.

ايتا على ذلك؟ أقترح أن نشحن في موعد أقصاه الأسبوع المقبل ، مع تأجيل هذه الميزة إذا لم يتم ذلك.

يا شباب أنتم رائعون. <3