Nunit: الطلب: أضف دعم المفهرسات إلى PropertyConstraint

الفكرة تعجبني.

لا يدعم C # الخصائص المفهرسة المسماة لكن VB.NET يدعمها. أعتقد أن بناء الجملة .Property("Name", index1, ...) يجب أن يكون محجوزًا لمفهرسات مسماة ، لذلك لا أريد أن أرى أنه يتم استخدامه لمفهرس افتراضي. أود أن أكون قادرًا على احترام لغة C # من خلال عدم مطالبة الأشخاص بتمرير معلمة الاسم.

ما رأيك في Has.Item("TEST1").EqualTo("1") أو Has.Index("TEST1").EqualTo("1") ؟

@ jnm2
يعد استخدام أسلوب "عنصر" أو "مفهرس" كاختصار أمرًا ملائمًا ، ولكن من الممكن بالفعل تغيير اسم المفهرس في C #: https://stackoverflow.com/questions/5110403/class-with-indexer-and-property- named -العنصر

@ Ch0senOne من الممكن تغيير الاسم. لكي أكون أكثر وضوحًا ، كان يجب أن أقول ، لا يمكن إنشاء مفهرس غير افتراضي في C #. على سبيل المثال ، لا يمكنك التصريح عن مفهرسين ، ولا يمكنك استخدام الاسم من C #.
التفكير في الأمر أخشى أن Has.Item("value") سيكون مربكًا جدًا مع Contains.Item . إذن ربما Has.Index("value") ؟

لذلك أؤيد Has.Index("IndexValue") للمفهرس الافتراضي و Has.Property("PropertyName", indexParams) للمفهرسات غير الافتراضية. سينتهي الأمر Has.Property للعمل مع المفهرسات الافتراضية أيضًا على الرغم من أن الأمر الاصطلاحي C # هو استخدام Has.Index .

أو إذا أردنا أن نكون لطيفين ، فيمكننا عمل Has.Index["IndexValue"] و
Has.Property("PropertyName")[indexparams] ... 😁

في الواقع ، أتساءل عما إذا كان بإمكاننا التخلص من Has.Item["AtIndex"] باستخدام صيغة المفهرس لتجنب الخلط بينه وبين Contains.Item("ItemValue") ... لست متأكدًا مما أفكر فيه!

دعونا نرى ما يعتقده أعضاء فريق @ nunit / framework-team الآخرون.

لقد حددنا بالفعل اتجاهًا للاستمرار في الخصائص باستخدام Lambdas بدلاً من السلاسل. يبدو أنه من الأفضل قضاء الوقت في ذلك. أنا على هاتفي لذا لا يمكنني إعطائك رقم الإصدار.

CharliePoole https://github.com/nunit/nunit/issues/26؟

هذا منطقي لـ Has.Property . يمكننا القيام به:

• Has.Property(_ => _.PropertyName[index1, ...])
• Has.Property(_ => _.PropertyName, index1, ...)

ما زلت أعتقد أنه لا ينبغي لنا القيام بأي شيء باستخدام Has.Property حتى تكون هناك حاجة إلى خصائص غير افتراضية ، والآن فقط قدم Has.Index(value1, ...) أو Has.Index[value1, ...] أو Has.Item[value1, ...] لـ المفهرسات الافتراضية الأكثر شيوعًا.

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

@ jnm2 لأخذك بعين الاعتبار ، يمكنك إنشاء مفهرس متعدد

this[string key1, string key2]

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

@ Crush83 نعم ، كان المقصود من بناء الجملة الخاص بي في index1, ... هو الإشارة إلى أنه يجب علينا اعتبارها مهما فعلنا.

لا أحب مفتاح المصطلحات إلا إذا كنا نتحدث عن كائن يمثل في الواقع قاموسًا أو مجموعة Contains.Key مفيد؟ هل يمكننا تحسينه؟)

لم يكن هناك تقدم بخلاف ما تراه هنا. نحن بحاجة إلى اقتراح. لوضع شيء ما هناك ، فإن المفضلة الحالية هي Has.Item(params object[] indexerArgs) والتي قد تستدعي المفهرس الافتراضي بغض النظر عن اسمه.
هل سيفعل هذا كل ما هو مطلوب حتى الآن؟

+1

@ nunit / framework-team هل ستدعم واجهة برمجة التطبيقات الجديدة التالية؟

namespace NUnit.Framework
{
    public abstract class Has
    {
        public static ResolvableConstraintExpression Property(string name);

+       public static ResolvableConstraintExpression Item(params object[] indexerArgs);
    }
}

namespace NUnit.Framework.Constraints
{
    public class ConstraintExpression
    {
        public ResolvableConstraintExpression Property(string name);

+       public ResolvableConstraintExpression Item(params object[] indexerArgs);
    }
}

من المحتمل أن أترك فئة IndexerConstraint داخلية حتى يكون هناك سبب لإضافتها إلى واجهة برمجة التطبيقات.

يبدو أمرا جيدا لي.

تصويت آخر لصالح ، أردت فقط هذه الميزة لاختبار وحدة التحكم. 🙂

@ jnm2 هل ما زالت هذه المشكلة شيئًا يريد الفريق فعله؟

لقد خضت المشكلة بسرعة ولأنني لا أفهم بالضبط أريد أن تبدو واجهة برمجة التطبيقات المدعومة - هل هي:

/// obj from the initial post example
Assert.That(obj, Has.Item("TEST1").EqualTo(1).And.Item("TEST2").EqualTo(2));

أو هو:

Assert.That(obj, Has.Item("TEST1", 1).And.Item("TEST2", 2));

؟

أنت على سبيل المثال يأخذ params object[] لذلك كنت تستخدم الخيار 2.

بافتراض اختيار. 2 ، هل ستكون المصفوفة مطلوبة كما لو تم توفير كائن واحد فقط ، تؤكد أن المفتاح موجود ، معلمتان - مفتاح وقيمة؟ مجموعات أخرى (أكثر أو أقل من المعلمات المتوقعة) ، فشل؟

Poimen نعم ، ونحن نقدر المساعدة!

الصفيف مطلوب لأن المفهرسات يمكن أن تأخذ أكثر من وسيطة واحدة. فمثلا:

public string this[int x] => "First indexer";

public string this[string x] => "Second indexer";

public string this[int x, int y] => "Third indexer";

ستستخدم Has.Item(42).EqualTo("First indexer") و Has.Item("42").EqualTo("Second indexer") و Has.Item(1, 2).EqualTo("Third indexer") .

انظر ، أنت تتعلم شيئًا جديدًا كل يوم - لقد افترضت أنه خطأ مطبعي ، عفوًا: see_no_evil: لم يكن من دواعي سروري استخدام مفهرس متعدد المفاتيح من قبل ...

حسنًا ، رائع ، سأبحث في تجميع شيء ما هذا الأسبوع.

@ jnm2 لقد قمت بإنشاء علاقات عامة لهذه المشكلة.

الشاغل الوحيد الذي لدي هو رسالة الخطأ التي ينتجها الرمز:

Has.Item(42)

رسالة الخطأ "مخترقة" بعض الشيء ، لكنني لست متأكدًا من أنظف طريقة لحل هذه المشكلة. "الاختراق" هو:
https://github.com/nunit/nunit/pull/3609/commits/96154ca6402c692cec5e0ae6947f9922e72799fe#diff -ceeee4b8399633f181b6bccd5a39eb32R72

@ Poimen آسف ، لست متأكدًا مما

@ jnm2 رسالة الخطأ التي تظهر هي:

  Expected: indexer [System.Int32]
  But was:  "not found"

الطريقة التي يتم بها تشكيل رسائل الخطأ للدالة StringifyArguments هي "اختراق" قليلاً.

لذا فإن سؤالي الذي تم التعبير عنه بشكل سيء هو أكثر إذا كانت هناك طريقة أنظف لإنتاج إخراج الرسالة المطلوبة.

@ jnm2 أعتقد أنني تناولت التعليقات على المراجعة (شكرًا لهم). تقول التسمية awaiting:contributor .

لست متأكدًا مما إذا كان هناك شيء آخر يتعين علي فعله لإعلامك بأنني "انتهيت": +1:

أعتقد أننا يجب أن نجعلها قريبة قدر الإمكان من الرسالة التي تظهر عندما يتعذر على Has.Property العثور على خاصية. يجب بعد ذلك استبدال property بـ default indexer واستبدال اسم الخاصية بـ accepting arguments [42] أو شيء من هذا القبيل. أميل إلى التفكير في أننا يجب أن نستخدم أحد مساعدي التنسيق الحاليين مثل MsgUtils.FormatCollection لإظهار قيم الوسيطة بدلاً من سرد أنواع الوسائط. على سبيل المثال ، قد تكون إحدى الوسيطات فارغة وتعمل مع مجموعة من الأنواع.

كلا ، هذا رائع! سيكون تعليقًا مثل هذا تمامًا في موضوع العلاقات العامة نفسه مثاليًا.

بالنظر إلى التأكيد:
ج #
Assert.That (tester، Has.em ("wow")) ؛

It producers the message:

المتوقع: المفهرس الافتراضي يقبل الوسيطات <>
ولكن كان: "غير موجود"

Given the assertion:
```c#
Assert.That(tester, Has.Item("wow").EqualTo(1));

تنتج الرسائل:

Default indexer accepting arguments < "wow" > was not found on NUnit.Framework.Constraints.IndexerConstraintTests+NamedIndexTester.

تم إنشاء هذا باستخدام الدالة MsgUtils.FormatCollection .

لذلك يتطابق أيضًا بشكل وثيق مع رسائل الخاصية ، مع التفاصيل المضافة.

أنا أحب الحالة الثانية كثيرا. لا تزال الحالة الأولى تبدو خاطئة من الناحية المعنوية لأنها تعرض أنواعًا من الحجج بدلاً من قيم الحجج. لدينا قيم وسيطة فقط ، ويمكن لكل قيمة وسيطة أن تتطابق مع مجموعة من أنواع الوسيطات في المفهرس. من المضلل جعل الأمر يبدو وكأنه يجب أن يكون هناك مفهرس مع وسيطة System.String لأن الوسيطة IEnumerable<char> ستعمل كذلك.

IEnumerable<char> هو حالة استخدام أحمق ... لكن بالتأكيد ، فهمت هذه النقطة.

لذا ، نعود إلى - معطى:
ج #
Assert.That (tester، Has.em ("wow")) ؛

producers the message:

المتوقع: المفهرس الافتراضي يقبل الوسيطات <"wow">
ولكن كان: "غير موجود"

For numbers it goes into the usual suffix - given:
```c#
Assert.That(tester, Has.Item(42d));

المنتجين:

  Expected: Default indexer accepting arguments < 42.0d >
  But was:  "not found"

تبدو الرسالة "المتوقعة" رائعة بالنسبة لي. تبدو الرسالة But was: "not found" كما لو كانت تتحدث عن نسخة سلسلة تحتوي على محتويات not found ، ولكن إذا كانت PropertyConstraint تتصرف بنفس الطريقة ، فإن الاحتفاظ بها على حالها هو الأفضل بالنسبة لي. تغيير PropertyConstraint سيكون خارج نطاق PR بشكل افتراضي. لا يزال بإمكاننا إجراء تغيير إذا أردت ذلك ، وقد وافقت أنا وشخص آخر في فريق العمل على التغيير.

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

But was: not found

لكن عودة ConstraintResult تضع علامات اقتباس السلسلة هناك.

للإشارة إلى إصدار الخاصية:
ج #
Assert.That (المختبر ، Has.Property ("NoItDoesNotHaveThis")) ؛

produces:

المتوقع: الخاصية NoItDoesNotHaveThis
لكنه كان:
""
لذلك لا توجد علامات اقتباس - ولكنها تُرجع النوع - وليست قيمة.

لم أكن متأكدًا مما إذا كانت إعادة تحميل زائد ConstraintResult سيكون حلاً؟

أعتقد أننا يجب أن نلتزم بما تفعله PropertyConstraint لتحقيق الاتساق. إن عرض التمثيل الافتراضي لقيمة actual ليس أسوأ شيء عندما تظهر الرسالة التي تفيد بأن ما فشل هو العثور على الخاصية.

إعادة فئة جديدة مشتقة من ConstraintResult هي كيفية تخصيص قيود أخرى لهذا ، نعم.

حسنًا ، رائع - يبدو مثل - معطى:
ج #
التأكيد على ذلك (الفاحص ، Has. البند (42 د)) ؛

producers:

المتوقع: المفهرس الافتراضي يقبل الوسيطات <42.0d>
لكنه كان:
""

يتطابق هذا مع رسالة قيد الخاصية.

@ nunit / framework-team والجميع ، آمل في الحصول على حل سريع لهذا السؤال نظرًا لأن العلاقات العامة الممتازة لـ Poimen (https://github.com/nunit/nunit/pull/3609) جاهزة للدمج بطريقة أخرى.

جلبت Dreamescaper انتباهي إلى أعلى في هذا الموضوع الذي فقدته: أخشى أن يكتب الناس ويقرأون Assert.That(collection, Has.Item("x")); معتقدًا أن Has.Item يعني Contains.Item .
يمكننا التفكير في إضافة شيء ما إلى رسالة الفشل ، ولكن هذا لن يساعد في مشكلة فهمها بشكل صحيح عند قراءة Has.Item في كود المصدر:

  Expected: Default indexer accepting arguments < 42.0d > (Did you mean to use Contains.Item?)

من ناحية أخرى ، لا أحب Has.Index(42) أو Has.Index(42).EqualTo(43) وهو ما اقترحته بدلاً من Item . المثيل لديه عنصر في الفهرس. لن تقول أن المثيل يحتوي على فهرس وأن الفهرس نفسه يساوي 43. الفهرس هو الشيء الذي تمرره ، 42.

بعض الخيارات

• استخدم Has.Item . التخلي عن المشاكل التي قد تسببها عند قراءة شفرة المصدر. ربما تضيف بعض عوامل التخفيف للمساعدة عند كتابة التعليمات البرمجية المصدر ، مثل مستندات XML والتلميحات في رسائل الفشل.
• استخدم Has.Index على الرغم من الاختلاط المحرج للمصطلحات.
• استخدم Has.ItemAt بدلاً من ذلك. Has.ItemAt(42).EqualTo(43) .

انتظر ، لقد وقعت في حب الاقتراح الأخير نظرًا لأنه يشبه طريقة LINQ ElementAt التي تُعطى فهرسًا وتعيد عنصرًا.

هل الجميع سعداء بـ Has.ItemAt ؟ نرحب بالاقتراحات ولكن مرة أخرى أود أن أكون سريعًا في احترام الوقت الذي

+1 مقابل Has.ItemAt :)

أتفق معك في أن Has.Item قد يكون محيرًا. أحب Has.ItemAt ولكن بما أنك تحب بنية LINQ ، فلماذا لا تستخدم Has.ElementAt ؟

لست متأكدًا من ElementAt ، لأنه ليس مكافئًا مباشرًا.
على سبيل المثال لـ Dictionary<string,string> LINQ's ElementAt (0) سيعيد الزوج الأول ، وسيفشل Has.ItemTo (0) .EqualTo ("...") ، حيث لا يوجد مفهرس يقبل الأعداد الصحيحة.

تضمين التغريدة يبدو أنه لن يكون من السهل العثور عليه ، لكنني لا أعرف لماذا أعتقد ذلك. أعتقد أنني أفضل Item لأننا سنقوم باستدعاء مفهرس على مجموعة / قاموس / بحث مفترض من نوع ما ، في حين أن ElementAt مخصص للعمل في الاستعلامات والعناصر العددية الأخرى التي ليست بالضرورة مجموعات . عادة ما تسمى عناصر المجموعة بالعناصر.

Dreamescaper هل تعتقد أن Has.ItemAt(4) يمكن أن يجعل الناس يعتقدون أنها تعمل تمامًا مثل ElementAt ، تعداد المفهرس بدلاً من الاتصال به؟

@ jnm2
ربما يمكن ذلك ، لكنني لا أعرف خيارًا أفضل (وأعتقد أنه لا يزال خيارًا أفضل بكثير من Has.Item).

@ jnm2 أنا في الواقع مرتبك بعض الشيء. بدأت هذه المشكلة حول الخصائص وما زالت تحمل عنوانًا. كيف سيكون موقع Has.Property و Has.Item على الارتباط أو التفاعل أو المقارنة مع بعضهما البعض في نظر المستخدم؟

[أدرك أن الخصائص وعناصر المجموعة يمكن التعامل معها على أنها مكافئة عند مستوى معين من التجريد ، لكنني لا أعتقد أن هذا هو مستوى التجريد الذي يعمل به معظمنا عادةً. : smiling_imp:]

كشيء NUnit 4.0 ، قد يكون من الجيد الاطلاع على كيفية استخدام المصطلحات في واجهة برمجة التطبيقات والتنظيف قليلاً. غالبًا ما تستخدم كلمة "عضو" كمكافئة لكلمة "عنصر" ولكنها قد تعني أيضًا خاصية أو طريقة أو متغير.

أشعر براحة أكبر مع ItemAt أكثر من ElementAt جزئيًا لأنه قد يبدو أننا نفوض أو نتبع نفس النهج المعين مثل Enumerable.ElementAt . ما أدهشني بشدة مع ElementAt(int index) كان أقل من تفاصيل كيفية عمله وأكثر من حقيقة أن هناك سابقة لواحق At في BCL ، خاصة المرتبطة بالمعامل المسمى index .

إذا كنت تستخدم هذا مع ILookup ، فكل فهرس من ILookup يُرجع عدة TElements ، وليس عنصرًا / عنصرًا واحدًا. يمكن أن يكون Has.EntryAt شيئًا يعمل مع المجموعات والقواميس وعمليات البحث متعددة العناصر لكل فهرس. رد فعلي الأولي هو أن Has.ItemAt الذي يُرجع IEnumerable<TElement> من ILookup ربما يكون مفهومًا بدرجة كافية .

ماذا عن رأيك؟ من الصعب أن ترى أكثر من شيء يعمل ، ولكن تفضيل الأغلبية هنا قد يساعد أيضًا في تحديد الاسم الذي سيكون من الأسهل على الأشخاص العثور عليه. الأشخاص إلى جانب @ nunit / framework-team ، لم أقصد استبعادك. إذا كنت تشاهد وكان لديك شعور قوي ، فهذه نقطة بيانات مفيدة دائمًا!

يؤكدCharliePoole Has.Property("X") أن المثيل له خاصية غير معلمة تسمى X . سيؤكد Has.ItemAt("X") أن المثيل يحتوي على مفهرس افتراضي (خاصية ذات معلمات ذات اسم غير ملائم ومعروف) يمكنه قبول معلمة سلسلة.

يؤكد Has.Property("X").EqualTo(3) أن المثيل يحتوي على خاصية غير معلمة تسمى X والتي تُرجع 3 إذا قمت باستدعاء موصّلها غير المعتمد get . سيؤكد Has.ItemAt("X").EqualTo(3) أن المثيل لديه مفهرس افتراضي (خاصية ذات معلمات ذات اسم مشهور وغير ذي صلة) تقوم بإرجاع 3 إذا قمت بتمرير السلسلة المحددة "X" لها get .

ما يجعل اسم المفهرس الافتراضي غير ذي صلة هو أن بناء جملة C # و VB و F # يمكن للجميع استدعاء المفهرسات الافتراضية دون تحديد اسم. (ومن ثم فإن مصطلح "افتراضي".) اللغة التي ليس لها مفهوم المفهرسات الافتراضية ولكن لديها مفهوم مفهرسات مسماة يجب أن تحدد الاسم. عادة ما يكون اسم المفهرس الافتراضي هو Item ، ولكن يمكن تسمية المفهرس الافتراضي بشيء تعسفي ولا يزال المفهرس الافتراضي لأن هذه اللغات ستظل قادرة على الاتصال به دون تحديد اسم. في C # ، يمكنك تحقيق ذلك باستخدام السمة [IndexerName("ArbitraryName")] .

@ jnm2 أنا في الواقع أفهم جميع عناصر لغة C # وما إلى ذلك حول المفهرسات ... ومع ذلك ...

أعتقد أن هناك احتمالية للخلط بين الممتلكات

• __كوني_ مفهرس للشيء الفعلي
• __إرجاع__ كائن به مفهرس
• __إرجاع__ مجموعة بها عناصر

أؤكد أن __you__ لن يتم الخلط بينكما وربما أتظاهر فقط عندما أتحدث معك (الطريقة السقراطية ، y 'know: wink :) ولكني أظن أن الكثيرين قد يجدونها مربكة وستقوم بشرحها للناس كثيرا نوعا ما.

أنا لست ضد الإضافة ولكني أعتقد أن الفروق المذكورة أعلاه يجب توضيحها في المستندات.

ملاحظة: لم أشعر بالاستبعاد على الإطلاق. : مبتسم:

تضمين التغريدة هل يمكننا جدولة هذا الاعتبار حتى نستقر على الاسم ، لأنه يبدو أنه لن يؤثر على الاختيار بين Has.ItemAt / Has.ElementAt / Has.EntryAt / إلخ؟ أم أن هناك نقطة فاتني وأنت تدعم اختيار تسمية معين بناءً على احتمال حدوث ارتباك؟

حتى الآن أميل نحو ItemAt . Dreamescaper ، هل ما زلت في CharliePoole لم أكن متأكدًا مما إذا كنت تعبر عن تفضيل لـ ElementAt أو مجرد مساعدتنا في التفكير خلال العملية.

كلما زاد عدد الأشخاص الذين يتناغمون على Has.ItemAt / Has.ElementAt / Has.EntryAt / أخرى ، زادت ثقتنا في ما سيجده الناس بديهيًا. أود فقط أن أتحدث عن أيهما يبدو أنه في الصدارة في اليوم التالي أو نحو ذلك ، لأننا سنفتقد الإصدار 3.13 بمثل هذا المبلغ الضئيل إذا استغرقنا وقتًا أطول من ذلك بكثير.

@ jnm2 فقط أحاول أن أفكر في الأمر من خلال نفسي وأشجع على نفس الشيء.

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

• Has.ItemAt("foo").EqualTo("bar")
• "Has.Property (" Bing "). With.ItemAt (" foo "). EqualTo (" شريط ")
• "Has.Property (" Bing "). With.One.EqualTo (" شريط ")

لذا أعتقد أنك على حق في أن الصياغة لا تهم أي خيارات

بالنظر إلى المدى الطويل ، أفضل استخدام الفهرسة الفعلية باستخدام أقواس مربعة. لكن هذا سيتطلب بالفعل تجميع تعبير القيد بدلاً من النمذجة كمجموعة من الفئات.

أعلم أن هذا أعلى من درجة راتبي: ابتسم: ، لكنني اعتقدت أنني سأكون هنا ...

أنا معجب بـ ItemAt .

قضيت وقتًا ، كما اقترح CharliePoole ، أفكر في بعض حالات الاستخدام. لقد توصلت إلى فكرة أن ElementAt يستخدم أكثر في مواقف IEnumerable ويمكن لمفهرسات اللغة التعامل مع أكثر من IEnumerable . جلست على السياج ElementAt للحظة ، ثم فكرت في:
ج #
تأكيد. أنه (...، له عنصر ("واحد" ، "اثنان")) ؛

against:
```c#
Assert.That(..., Has.ItemAt("one", "two"));

يبدو أن التعبير عن مفهرسات القيمة المتعددة يعد أمرًا طبيعيًا أكثر من ItemAt في ما سبق.

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

أنا أيضًا أفضل ItemAt ، لذلك دعونا نسميها أغلبية ونحكم لصالح ذلك 😺

لمنع الالتباس ، دعنا نتأكد من توثيق ذلك بسرعة بعد الانتهاء وإدراجه في ملاحظات الإصدار.

Poimen Re: درجة راتبك ، لا تقلل من شأن مدى

وفيما يتعلق بدرجة الراتب ، نظرًا لأن كل شخص هنا يحصل على راتب سنوي يبلغ حوالي 0 دولار أمريكي يعمل في NUnit ، أعتقد أننا جميعًا في نفس درجة الراتب 😝

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

Assert.That(new[] { 1, 2, 2 }, Has.ItemAt(3));
Assert.That(new[] { 1, 2, 2 }, Has.No.ItemAt(3));

يبدو أنه من الآمن إزالة القيود الموجودة حتى يكون لدينا المزيد من الوقت للتفكير في الأمر. أفضل فتح إصدار منفصل Has.Indexer(typeof(Type1), typeof(Type2), ...) لفحص وجود المفهرس ، و Has.ItemAt(arg1, arg2, ...) لتشغيل المفهرس فعليًا وتأكيد الأشياء المتعلقة بالقيمة الناتجة.

هل سيعترض أي شخص على شحن Has.ItemAt(3) مبدئيًا لعدم حل مشكلة القيد و Has.ItemAt(3).EqualTo(4) كحل؟

Has.Indexer أمر منطقي بالنسبة لي. أفترض أنك ستدعم أيضًا Has.Indexer<T>() ، Has.Indexer<T1, T2>() ، وما إلى ذلك من أجل التوافق مع القيود الأخرى.

شكرا على ملاحظاتك! أعطيت الضوء الأخضر لطلب السحب لجعل Has.ItemAt (...) لم يعد ذاتيًا ، وقدمت https://github.com/nunit/nunit/issues/3690 لتتبع Has.Indexer لتوفير هذه الإمكانية.