Jest: سياق مقروء من قبل الإنسان للتوقعات

مهلا! لذلك اعتدنا بالفعل على الحصول على هذا في Jasmine ولكن وجدنا أنه على مدى آلاف ملفات الاختبار في FB ، لم يستخدمه أحد. حتى الآن نقوم بطباعة رسالة خطأ لطيفة بمعلومات تقريبية وتتبع مكدس سيؤدي إلى التوقع (تمامًا كما هو الحال في لقطة الشاشة الخاصة بك). أوافق على أنه يمكننا طباعة السطر الذي يتم طرحه ولكن في كثير من الأحيان يكون التأكيد بطول عدة أسطر:

expect(a).toEqual({
  …
});

لذلك لن يبدو هذا جيدًا بالفعل وعلينا استخدام المحلل اللغوي لتحليل JS واستخراج المعلومات ذات الصلة (وطي الأسطر الطويلة) أو شيء مشابه لجعلها جميلة.

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

لقد اعتدنا بالفعل على الحصول على هذا في Jasmine ولكن وجدنا أنه على مدى آلاف ملفات الاختبار في FB ، لم يستخدمه أحد

cpojer لذا فإن النمط هو التفاف كل تأكيد في it ؟ و / أو الثقة فقط في أرقام الأسطر؟

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

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

إعادة البناء في سطر واحد يمكن أن يشجع على المزيد من المعلومات الدلالية في التأكيد؟ ربما؟

const adminUser = {
  …
}
expect(a).toEqual(adminUser);

أنا شخصياً أعتقد أننا نعرض معلومات كافية في الوقت الحالي ولكن يسعدنا إعادة النظر

يوضح المثال أعلاه أنه من الصعب اكتشاف التأكيد الذي فشل بالضبط ما لم تقم بإضافة أغلفة مطولة (IMO) حول كل شيء. هذا صحيح بشكل خاص في بيئة transpiled حيث أرقام خطوط sourcemap ليست دقيقة دائمًا. أعتقد أن الفهم السريع والدقيق للكسر وأين يكون مهمًا ، وكذلك الاختبارات الموجزة.

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

لقد قدمت بعض الاقتراحات أعلاه:

• معلمة اختيارية إضافية لطرق التأكيد
• رسالة سياق بالسلاسل

هل تبحث عن شيء أبسط أو مختلف؟

ياtimoxley! لقد فكرنا بالفعل في إضافة شيء مثل هذا.

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

على سبيل المثال ، هنا في الحالة الثانية ، لن نعرف ما إذا كانت الحجة قريبة أم رسالة خطأ

expect(555).toBeCloseTo(111, 2, 'reason why');
expect(555).toBeCloseTo(111, 'reason why');

الاقتراح الثاني لن ينجح لأن المطابق سيرمي بمجرد أن لا يلبي شيء ما التوقعات

expect(1).toBe(2)/* will throw here */.because('reason');

يمكننا إرفاق السبب قبل تنفيذ المطابق ، مثل هذا:

expect(1).because('reason').toBe(2);
// or 
because('reason').expect(1).toBe(2);

لكن واجهة برمجة التطبيقات هذه لا تبدو جيدة حقًا.

خيار آخر هو إضافة وسيطة ثانية إلى expect

expect(1, 'just because').toBe(2);

ولكنه يشبه إلى حد كبير الخيار السابق.

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

في الماضي ، كان الحل الأفضل هو إنشاء أدوات مطابقة مخصصة. سنقدم expect.extend في الإصدار التالي من Jest وسيسمح لك بإنشاء المطابقات بسهولة مثل:

expect(a).toEqualMySpecificThing(…)

مما يسمح لك بكتابة المزيد من رسائل الفشل التعبيرية. لقد رأيت أن هذا يستخدم كثيرًا في مشاريع مثل Relay. شاهد جميع المطابقات: https://github.com/facebook/relay/blob/master/src/tools/__mocks__/RelayTestUtils.js#L281

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

cpojerdmitriiabramov يعتذر عن التأخير.

سيكون من الرائع استخدام وسيطة ثانية لـ expect أو تسلسل سبب بـ .because . ما الذي يجب القيام به لتحقيق ذلك أم لا؟

لا يريد المهندسون إضاعة الوقت في كتابة الاختبارات

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

بالنسبة لبعض الأرقام الملموسة ، باستخدام المثال البسيط من تعليقي أعلاه ، للحصول على تأكيدات مكافئة + سياق مع شريط ، يتطلب Jest من المبرمج كتابة ضعف كمية النموذج الاحتفالي تقريبًا:

• 1.8x الخطوط (6 مقابل 11)
• 2x المسافة البادئة (1 مقابل 2)
• 2x الأقواس / الضفائر (24 مقابل 48) !

يمكن تحسين هذا!

// tape
test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
  t.end()
})

// jest
describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

تحديث : أفترض أنه يمكنك كتابة اختبارات الدعابة على سطر واحد مع الأسهم:

// jest
describe('api works', () => {
  test('api without magic provides no items', () => expect(api()).toEqual([]))
  test('api with zero magic also provides no items', () => expect(api(0)).toEqual([]))
  test('api with magic enabled provides all items', () => expect(api(true)).toEqual([1,2,3]))
})

هذا يجعل بعض الخطوط الطويلة ، لكنه يحسن الإحصائيات التي قارناها سابقًا إلى حد ما:

• 0.8x الخطوط (6 مقابل 5)
• 1x المسافة البادئة (1 مقابل 1)
• 1.75x الأقواس / الضفائر (24 مقابل 42)

ومع ذلك ، أعتقد أن وجود وصف الاختبار في بداية السطر ، بدون فاصل سطر ، يجعل من الصعب تحليل المنطق بصريًا لأنه يضع "عنصر" الاختبار ، أي التأكيدات الفعلية ، في موضع عمود تعسفي.

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

/* api without magic provides no items */ expect(api()).toEqual([])
/* api with zero magic also provides no items */ expect(api(0)).toEqual([])
/* api with magic enabled provides all items */ expect(api(true)).toEqual([1,2,3])

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

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

استخدم الوسيطة الأخيرة لكل دالة مطابقة بعد ذلك؟

لن تنجح إلا إذا أضفناها كوسيطة ثانية لـ expect .
لا يمكننا إضافتها كحجة أخيرة لكل دالة مطابقة بسبب الغموض
على سبيل المثال

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

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

cpojer ليس من الواضح ما إذا تم استبعاد طريقة الياسمين (وغيرها) expect(value).toBe(something, 'because message') ؟

أحد الأمثلة على ذلك هو اختبار العناصر القابلة للملاحظة redux-saga / إعادة الملحوظة حيث تقوم باختبار آلة الحالة . من المفيد جدًا أن يكون لديك رسالة وصفية حول أي حالة فشلت فيها. هذا المثال مفتعل ، لذا فإن الأوصاف كذلك ، على الرغم من ..

jayphelps نحن لم نعد نستخدم طريقة الياسمين بعد الآن منذ أن أعدنا كتابة جميع أدوات مطابقة الياسمين

@ dmitriiabramov آسف سؤالي لم يكن واضحًا. هل حُكم على طريقة عمل الياسمين بإضافته مرة أخرى؟ يفعلون نفس الشيء الذي يسمحون به.

jayphelps كما قلت من قبل ، لن يعمل مع جميع المطابقات بسبب الغموض.

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

ويمكن تمديد المطابقات المزاحه مع حزم طرف ثالث لا أعتقد أنه من الجيد العبث بقائمة الحجج

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

expect(123, 'jest because').toEqual(123);

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

beforeEach(someSharedSetup);
test('reason or description', () => expect(1).toBe(1));

انها مجرد سطور قليلة :)

أو يمكنك حتى وضعها في مكالمة أخرى describe() .

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

it('stuff', () => {
  const generator = incrementAsync();

  expect(generator.next().value).toBe(
    call(delay, 1000)
  );

  expect(generator.next().value).toBe(
    put({ type: 'INCREMENT' })
  );

  expect(generator.next()).toBe(
    { done: true, value: undefined }
  );
});

أو يمكنك حتى وضعها في مكالمة وصف () أخرى.

هل يمكنك تفصيل هذا؟ تداخل وصف المكالمات كان AFAIK فقط لتقسيم عناوين الأقسام ، ما زالت الاختبارات تعمل بشكل متزامن ، أليس كذلك؟

مجموعات الاختبار (الملفات) تعمل بشكل متزامن ، ولا يتم تشغيل مكالمات test() .

بدأت أعتقد أن شيئًا مثل

test('111' () => {
  jest.debug('write something only if it fails');
  expect(1).toBe(2);
});

يمكن أن يكون شيئا

من هذه المناقشة وهذا المستودع ، أعتقد أنه سيكون جيدًا ودلاليًا:

it('has all the methods', () => {
  since('cookie is a method').expect(reply.cookie).toBeDefined();
  since('download is a method').expect(reply.download).toBeDefined();
  since('end is a method').expect(reply.end).toBeDefined();
  // ...
});

الاستخدام مشابه لـ because واحد ، لكنه أكثر منطقية من الناحية الدلالية.

إذا كنت تحب هذا ، فقد أتمكن من العمل على العلاقات العامة بإضافة وظيفة since .

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

من فضلك لا تقل "أعد كتابة مجموعات الاختبار لتكون أبسط". الشيء الوحيد الذي يكرهه المهندسون أكثر من _writing_ مجموعات الاختبار هو _rewriting_ مجموعات الاختبار.

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

حصلت على عرض تجريبي بسيط "النموذج الأولي" ، سأحتاج إلى تنفيذ العودية الآن. إنه غلاف رقيق يستخدم البروكسيات حول المتغيرات العامة ثم فوق كل طريقة. ومع ذلك ، لا تدعم المتصفحات القديمة البروكسيات ولا يمكن تعويضها ، لذا قد لا يكون مقبولاً لـ Jest. هذا هو الهيكل العام للغلاف:

const since = (text) => {
  return new Proxy(global, {
    get: (orig, key) => {
      return (...args) => {
        try {
          const stack = orig[key](...args);
          return new Proxy(stack, {
            get: (orig, key) => {
              return (...args) => {
                try {
                  const ret = orig[key](...args);

                  // ... implement recursion here

                } catch (err) {
                  console.log('2', key, text, err);
                  throw err;
                }
              }
            }
          });
        } catch (err) {
          console.log('1', key, text, err);
          throw err;
        }
      };
    }
  });
};

هناك ثلاثة خيارات واقعية:

• هذه الطريقة مقبولة لذا يجب إضافتها إلى مكتبة Jest الرئيسية. أقوم بتنظيفه وإنشاء علاقات عامة.
• تعمق في Jest وتعديل المكتبة الأساسية. الكثير من العمل ، لذلك لن تفعل أي شيء حتى يقول بعض الأعضاء شيئًا شبه رسمي حول هذه القضية / الاتجاه.
• قم بإنهائه بهذه الطريقة وانشره كحزمة. غير مرغوب فيه لأنه لا يمكن اكتشافه بسهولة.

تحرير: شاهده في العمل:

describe('Test', () => {
  it('works', () => {
    since('It fails!').expect('a').toEqual('b');
  });
});

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

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

عندما كسرت شيئًا وفشلت ، مع Jest ، يجب أن أقوم بتصحيحه يدويًا أو إضافة تسجيل أو أي تعديل. وهو أقل ملاءمة بكثير من مجرد إلقاء نظرة على نتائج تشغيل الاختبار.
في Jasmine على سبيل المثال ، لدينا القدرة على طباعة بعض السياق لفهم الفشل بشكل أكبر.
في إطار JUnit الأكثر شيوعًا للاختبار في Java ، لدينا نفس الميزة أيضًا.

آسف إذا كنت مخطئًا ، لكنني لا أرى أي حجج _technology_ مضادة لهذه الميزة هنا. وأشياء مثل "لا ينبغي إضافة هذا لأنه لن يبدو جيدًا" هي أشياء سخيفة.

هل يمكننا إعادة الفتح؟ حتى jest.debug() كما اقترحه @ aaronabramov أعلاه سيكون مفيدًا لي.

This:

it('has all the methods', () => {
    since('cookie is a method', () => expect(reply.cookie).toBeDefined());
});

can be supported by adding this:


// setupTestFrameworkScriptFile.js
// http://facebook.github.io/jest/docs/configuration.html#setuptestframeworkscriptfile-string
global.since = (explanation, fn) => {
    try {
        fn();
    } catch(e) {
        e.message = explanation + '\n' + e.message;
        throw e;
    }
};

أيضًا ، تبدو رسالة الياسمين المخصصة مشابهة لما هو مطلوب:

describe('test', function() {
  it('should be ok', function() {
    since(function() {
      return {'tiger': 'kitty'};
    }).
    expect(3).toEqual(4); // => '{"tiger":"kitty"}'
  });
});

هل هناك أي خطط لإعادة فتح هذا؟ يبدو أنه كانت هناك نسخ مكررة من هذه المشكلة مؤخرًا. أنا أتطلع أيضًا لعرض رسالة مخصصة عند فشل الاختبار.

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

ما الذي يتطلبه الأمر بالنسبة إلى الوسيطة الثانية لتوقع () أو التنسيق منذ ذلك الحين () ليتم قبولها على أنها علاقات عامة؟ أنا على استعداد للتبرع ببعض الوقت للمساعدة في ذلك.

لقد قرأت للتو الخيط ورأيت حججًا جيدة من كلا الجانبين. أريد بالتأكيد آلية لتقديم رسالة خطأ مخصصة لنفس السبب الذي نشره timoxley في الأصل. أفعل الآن شيئًا كهذا:

import assert from 'assert'
import chalk from 'chalk'

test('api works', () => {
  assert.deepEqual(
    api(),
    [],
    chalk.red('api without magic provides no items')
  )
  assert.deepEqual(
    api(0),
    [],
    chalk.red('api with zero magic also provides no items')
  )
  assert.deepEqual(
    api(true),
    [1, 2, 3],
    chalk.red('api with magic enabled provides all items')
  )
})

هذا في الواقع يعمل بشكل جيد بشكل ملحوظ ، لكني أود تجنب الاضطرار إلى استخدام الطباشير للحصول على اللون الأحمر (مطبوعات بدون لون بخلاف ذلك) وأنا أفضل أن يتم دعم ذلك بـ expect .

لا يهمني حقًا كيف يتم تنفيذه بأمانة. ولكن إليك بديل لـ since فقط لإلقاء شيء آخر في حالة ما إذا كان الآخرون يفضلونه:

const expectWithMessage = expect.withMessage(
  'api with magic enabled provides all items'
)
expectWithMessage(api(true)).toEqual([1, 2, 3])

// could be rewritten like
expect
  .withMessage('api with magic enabled provides all items')(api(true))
  .toEqual([1, 2, 3])

لست متأكدًا من أنني أحب ذلك أفضل من since . أنا جيد مع أي شيء ، أود حقًا أن أحصل على هذا :)

يا وللتعليق على التعليق:

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

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

مرحبا cpojer أي تحديثات على هذا؟

تعمل Jest بشكل رائع بالنسبة لي باستثناء هذه المشكلة ... في الوقت الحالي ، أواجه صعوبة في إصلاح تأكيد فاشل داخل حلقة for مثل
expectationsArray.forEach(expectation => expect(...))

من الصعب معرفة بالضبط التوقعات التي تفشل بدون رسالة خطأ مخصصة (إلا إذا كنت أفعل ذلك بشكل خاطئ ..؟)

شكرا لك

@ mj-airwallex ، من الجيد أن تختتم التوقعات بـ test في حلقة for على سبيل المثال:

const expectationsArray = [[0, 'a'], [1, 'b']];

expectationsArray.forEach(([expectation, desc]) => {
  test(`test ${desc}`, () => {
    expect(expectation).toBeGreaterThanOrEqual(2);
  });
});

لدي أيضًا مشكلة مع الدعابة بسبب الحاجة إلى تقديم رسائل مخصصة أثناء التوقعات. يبدو أن التفاف التوقعات تحت test يعمل في الحالات التي لا توجد فيها حاجة للمكالمات غير المتزامنة. ولكن نظرًا لأن Jest لا يمكنه التعامل مع describe (# 2235) بإرجاع وعد ، فلا يمكننا إنشاء اختبارات باستخدام مكالمات غير متزامنة مع تغليفها بـ test . ولا يمكن أن يكون لدينا عدة test متداخلة.

فيما يلي مثال لتوضيح المشكلة:

async function getArray() {
  return [0,0,0,0,0,0]
}

describe('Custom messages with async', async () => {
  const array = await getArray();
  array.forEach((item) => {
    test(`test${item}`, () => {
      expect(item).toBe(0)
    });
  });
})

أي أفكار حول كيفية التعامل مع هذا؟

بالنظر إلى المشكلة في OP ("سيكون من الجيد أن يكون هناك سياق يمكن قراءته من قبل الإنسان والذي أوضح على الفور ما هو التوقع الذي فشل") ، أعتقد أنه تم حلها الآن. اعتبارًا من Jest 22 نطبع سياق التأكيد الفاشل. هل لا تزال هناك حاجة إلى الرسالة الإضافية؟ إذا كان _is_ ، فيمكن أن يكون تعليقًا برمجيًا أعلى أو جانب التأكيد

الوصف غير المتزامن هو مشكلة أخرى (لن يساعدها الإطار الكودي المضاف)

أعتقد أنني لن أستخدم الوصف غير المتزامن وبدلاً من ذلك استخدم beforeEach أو beforeAll

kentcdodds ، هل يمكنك تقديم مثال عن كيفية التعامل مع هذا باستخدام beforeEach أو beforeAll ؟ إذا حاولت إنشاء جميع نتائج المكالمات غير المتزامنة الضرورية في beforeEach و beforeAll فسوف يفرض عليك في النهاية إنشاء test متداخلة وهو غير مسموح به.

آه ، فاتني ما كنت تفعله بهذه المكالمة غير المتزامنة. نأسف لذلك 😅 نعم ، لا يمكنك فعل beforeEach أو beforeAll للقيام بذلك.

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

tojuhaka جرب هذا: https://github.com/negativetwelve/jest-plugins/tree/master/packages/jest-plugin-context

بالنظر إلى المشكلة في OP ("سيكون من الجيد أن يكون هناك سياق يمكن قراءته من قبل الإنسان والذي أوضح على الفور ما هو التوقع الذي فشل") ، أعتقد أنه تم حلها الآن.

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

بدأت للتو في استخدام Jest وأنا أفتقد ميزة مثل هذه. حالة الاستخدام الخاصة بي:
يفشل الاختبار حيث أؤكد أن صدق خاصية كائن ما. سيساعدني ذلك على فهم الفشل بشكل أسرع إذا تمكنت من تسجيل الكائن في حالة فشل التأكيد.

يمكنك استخدام toHaveProperty لذلك.

test('property', () => {
  expect({foo: 'bar'}).toHaveProperty('baz', 'foobar');
});

إذا كنت تريد فقط التحقق من وجودها ، فقم بإسقاط الوسيطة الثانية. إذا كنت تريد فقط التأكيد على أن لها قيمة _ بعض_ ، يمكنك استخدام expect.anything() .
toMatchObject هو بديل آخر.

يمكنك أيضًا استخدام assert إذا كنت تريد.

test('property', () => {
  const obj = {foo: 'bar'};
  assert.equal(obj.baz, 'foobar', JSON.stringify(obj));
});

شكرا على الاكرامية. assert.equal(obj.baz, 'foobar', JSON.stringify(obj)); سيؤدي المهمة في حالتي الخاصة.

SimenBmpseidel ما هو التأكيد؟ هل هي مكتبة طرف ثالث؟ لا يمكنني العثور على أي شيء في مستندات الدعابة.

sharikovvladislav assert هي وحدة عقدة أساسية https://nodejs.org/api/assert.html

تضمين التغريدة لم اعرف. شكرا لك. إنها تعمل.

أنا أستخدم جزء التعليمات البرمجية التالي لاختراق هذا القيد من إطار العمل (في TypeScript ولكن فقط قم بإزالة التعليقات التوضيحية لنوع JS)
export const explain = (expectation: () => void, explanation: string) => { try { expectation(); } catch(e) { console.log(explanation) throw e; } }

مرحبا،
أنا مندهش من أن أحدا لم يذكر الحلقات بعد. لن تكون الرسالة مجرد سلسلة ، بل سلسلة ديناميكية تعتمد على تكرار الحلقة.
jest-plugin-context جميل ، شكرًا على هذه الأعمال ، لكنها ثقيلة بعض الشيء ولا تزال المشكلة الأولية متعلقة بـ imo.
انظر إلى هذا الاختبار

describe('MyStuff', () => {
    it('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];
      expectedKeys.forEach((key) => {
        expect(wrapper.find({ id: key }).length).toEqual(1);
      });
    });
  });

حظا سعيدا في العثور على الجاني الخاص بك. الآن يجب علي إضافة سطر أو اختبار كائن بدلاً {len:.., key:..} ، هذا ليس نظيفًا وغير سهل الاستخدام.
أعتقد أن حالة الاستخدام هذه مناسبة ، بالنسبة للنماذج وفحص عرض العناصر على سبيل المثال.
يمكن أن يكون بناء الجملة بسيطًا مثل toEqual(1).context("my message") أو toEqual(1, "my message") (على الرغم من أنني بالطبع أعرف أن التنفيذ دائمًا ما يكون أصعب ، وأنا أحترم العمل الرائع الذي قمت به مع Jest).

ربما استخدم نفس التنسيق مثل chai - على سبيل المثال ، أضف الرسالة كوسيطة ثانية إلى المكالمة المتوقعة:

expect(foo, 'this detail').toEqual(2)

تي

تم استخدام الياسمين من قبل ، لذا جئت إلى هنا لتجد أنه غير مدعوم.
ومع ذلك ، فإن هذه الأشياء كلها وظائف. لا يمكننا فعل شيء مثل:

describe('MyStuff', () => {
    describe('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];

      expectedKeys.forEach((key) => {
        it(`contains key "${key}"`, () =>
          expect(wrapper.find({ id: key }).length).toEqual(1)
        )
      })
  });
});

akkerman حل لطيف. منذ وصفها وهي عبارة عن كرات كروية سحرية مقدمة من الدعابة ، يجب أن أعترف أنها يمكن أن تشعر بالغموض ، لم أكن متأكدًا من أن الكتابة في حلقة يمكن أن تنجح.

ماذا عن تسلسل معدل آخر؟

expect(foo).toEqual(bar).because('reason with %s placeholders')

أو ربما وظيفة

expect(foo).toEqual(bar).explainedBy((result) => `Lorem ipsum ${result}`)

أعتقد أن معدلًا آخر يصبح سريعًا غير قابل للقراءة.
تي

2018-04-19 13:47 GMT + 02: 00 λ • Geovani de Souza [email protected] :

ماذا عن تسلسل معدل آخر؟

توقع (foo) .toEqual (شريط). لأن ("سبب مع٪ s عناصر نائبة")

أو ربما وظيفة

توقع (foo) .toEqual (شريط) .explainedBy ((نتيجة) => Lorem ipsum ${result} )

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/facebook/jest/issues/1965#issuecomment-382705387 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAM5PwBCvET1KdEDeDEF7gGo708Naj8oks5tqHlSgaJpZM4Kc6Uu
.

-

تارجي هيوز
موبايل: 920 63413

الطريقة التي يعمل بها expect هي الرمي ، لذلك لن ينجح ذلك على أي حال.

أعتقد أن أفضل البدائل هي إما expect(something, 'some helpful text on failure').toEqual(somethingElse) أو expect.context(something, 'some helpful text on).toEqual(somethingElse) ، لكنني لا أحب أيًا منهما

هل يمكن إعادة فتح هذا؟ يبدو أن Jest لا يزال ليس لديه حل جيد لاختبار كيفية تغير الحالة عبر تفاعلات متعددة ، على سبيل المثال:

• اختبار كيفية تغير حاوية React ذات الحالة استجابة لسلسلة من الأحداث
• اختبار كيفية تغير صفحة الويب من خلال تفاعلات متعددة باستخدام محرك العرائس

تتطلب كلتا الحالتين تنفيذ سلسلة من الإجراءات ، والتأكيد على كيفية تغير الحالة (أو عدم تغييرها) بعد كل إجراء ، لذلك فإن اختبارات التأكيد المتعدد ضرورية في بعض الأحيان. ليس من الممكن دائمًا حل هذا النوع من المشكلات باستخدام beforeEach .

ما زلت أجد مواقف يكون فيها هذا مفيدًا حقًا. على وجه التحديد عندما أقوم بتشغيل تفاعلات وتأكيدات متعددة كما يشرح callumlocke .

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

فيما يلي ملخص للحلول المقترحة:

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

expect(api(), 'api without magic provides no items').toEqual([])
expect(api()).because('api without magic provides no items').toEqual([])
since('api without magic provides no items').expect(api()).toEqual([]))
because('api without magic provides no items').expect(api()).toEqual([]))
jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

لاحظ أن تتبع .because() غير ممكن ، لذلك لا يتم تضمينه كخيار.

يتم دعم جميع الخيارات الأربعة في المجموعة الأولى اليوم. أنا شخصياً أجد أن الخيار الأول (إطار رمز مع تعليق) يعمل بشكل رائع. وحتى أفضل من ذلك هو استخدام المطابق المخصص (الخيار 4).

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

مرحبا،
لديك في الأساس بعض حالات الاستخدام:

• اختبارات تأكيدات متعددة (تحتاج إلى تأكيد أشياء متعددة في الاختبار)
• سياق التوكيد الذي تم إنشاؤه ديناميكيًا (تريد متغيرًا في رسالة الفشل لتوضيحها ، على سبيل المثال لطباعة حقل معين من العنصر الفاشل لديك لأنك حصلت على الكثير من الاختبارات)
• التأكيدات المُنشأة ديناميكيًا (تقوم بعمل حلقة تولد التأكيدات)

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

نظرًا لأن حالات الاستخدام الديناميكي هذه لا تزال نادرة ، يجب أن نلتزم بالحل الذي يتطلب الحد الأدنى من العمل للقائمين على الصيانة. أنا شخصياً أحب الحل because/since ، لأنه يبدو بسيطًا للغاية. أعتقد أن التنفيذ سيتم في الغالب التفاف expect في try/catch يطبع الرسالة ويعيدها؟
يبدو jest.debug غريبًا ، بالنسبة لي فإن التصحيح هو طباعة رسالة حتى لو نجحت الاختبارات بالفعل
خيار "الوسيطة الأخيرة" جيد أيضًا ولكني لست متأكدًا مما إذا كان ممكنًا لأن expect يمكنه قبول عدد متغير من الوسائط؟

أنا بخير مع أي خيار. أنا فقط أريد الميزة. أنا لست ضخمًا على jest.debug API أيضًا ، ولكن إذا كان هو الوحيد الذي يبدو منطقيًا ، فأنا على ما يرام معه لأنني أريد هذه الميزة فقط.

@ kentcdodds ماذا عن الخيارات الأربعة الموجودة؟

@ eric-burel هل رأيت test.each و describe.each مضافًا في Jest 23 (متاح كمستقل لـ Jest <23)؟

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

1. expect(api(), 'api without magic provides no items').toEqual([])
2. because('api without magic provides no items').expect(api()).toEqual([]))
3. since('api without magic provides no items').expect(api()).toEqual([]))
4. expect(api()).because('api without magic provides no items').toEqual([])
5. jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

يعد (test|describe).each أمرًا رائعًا ، ولكنه لا يحل المشكلة حيث تريد الحصول على إجراءات / تأكيدات متعددة في اختبار واحد.

الميزة موجودة اليوم مع أربعة خيارات:

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

ما هو الخطأ في هؤلاء؟ يبدو أن الحلول _ الجديدة_ المقترحة أفضل بشكل هامشي من هذه الحلول الحالية. ما هي الفوائد التي يجلبونها على ما لدينا والتي تبرر تكلفة الصيانة؟

rickhanlonii نيس لم أكن أعرف شيئًا عن test.each ، إنها حقًا ميزة رائعة ، شكرًا للإشارة إلى ذلك. أعتقد أنه يحل مشكلة حالة الاستخدام الثالثة ، الاختبار الذي تم إنشاؤه ديناميكيًا من مصفوفة.

لذلك تركت الثانية التي أدرجتها: وجود رسالة فشل إنشاء ديناميكيًا ، مما يجعل تصحيح الأخطاء أسرع. ليس لدي الكثير من حالات الاستخدام في الوقت الحالي ، ربما عند اختبار قيمة حقل كائن ، قد ترغب في طباعة الكائن بأكمله عند الفشل. هذا IMO شرعي ، مثل أي شيء يجعل اختبار الكتابة أسهل ، حتى لو كان هامشيًا أو زائداً قليلاً. بعد كل شيء يمكننا كتابة كلٍّ من it و test ، ما لم يكن هناك اختلاف لا أعرفه عن هذا ، فهو في الغالب من أجل الراحة.
إنه أمر هامشي ولكنه في الحقيقة شيء متوقع (بدون تورية) من قبل المستخدمين ، كما يظهر هذا الموضوع.

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

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

كان Mocha يفعل هذا إلى الأبد ... إنه أحد الأسباب التي دفعتني للتخلي عن Jasmine منذ سنوات (السبب الآخر هو أنه يسخر من المؤقت بشكل أفضل.) إذا لم أكن مضطرًا للانضمام إلى عربة React ، فلن أستخدم Jest أو أي شيء آخر مشتقات الياسمين الأخرى.

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

mattphillips هل تعتقد أنه من الممكن القيام بشيء مشابه لسلسلة الدعابة هنا للسماح بوجود حل في أرض المستخدمين؟ على سبيل المثال ، الوسيطة الثانية لـ expect

بصراحة ، هذا شيء قياسي جدًا في معظم أطر اختبار JS. محبط للغاية لعدم العثور عليه في Jest لأننا نكتب جميع اختباراتنا برسالة خطأ مخصصة.

SimenB آسف أنا فقط لاحظت رسالتك هذا الصباح!

نعم ، هذا ممكن في userland ، لقد طرقته للتو وأصدرته كـ jest-expect-message https://github.com/mattphillips/jest-expect-message

نرحب بملاحظات: ابتسامة:

رائع ، شكرا لفعل ذلك!

تضمين التغريدة

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

شيئان:

1. إضافة وسيطة ثانية اختيارية للتوقع () بالكاد تجعل أي شيء أكثر صعوبة للمطورين.
2. آخر شيء يريد المطورون فعله هو إضاعة الوقت في تصحيح الأخطاء التي تسبب في فشل الاختبار. غالبًا ما تكون التوقعات مقابل الاستلام طريقة جيدة للتحقق مما إذا كان الشرط قد تم الوفاء به ، ولكن غالبًا لا يوجد سياق كافٍ لسبب فشلها.

لقد استخدمت Mocha / Chai ، وكذلك الشريط ، قبل مجيئي إلى Jest ، وهذا حقًا يفسد الصفقات. ما الذي يتعين علينا القيام به للحصول على دعم رسالة مخصصة في توقع؟

إن إخبارنا بأن نتوقع. exend من أجل إنشاء مُطابق مخصص يبدو تمامًا مثل ما كنت تحاول تجنبه في حجتك الأولى: "لا يريد المهندسون إضاعة الوقت في كتابة الاختبارات."

أجد أنه من السهل فتح اختبار الوحدة وإلقاء نظرة على رقم السطر ، وبالتالي فإن حالة الاستخدام في OP لا تزعجني.

حالة الاستخدام التي تزعجني هي عندما يكون لدي حلقة داخل اختبار ، على سبيل المثال لاختبار كل قيمة لتعداد ، على سبيل المثال مثل هذا:

it("Should contain at least one word of every wordType", () => {
  for (const wordType of wordTypes) {
    expect(words.find((word) => word.wordType === wordType)).toBeTruthy();
  }
});

إذا فشل ذلك ، فأنا لا أعرف قيمة نوع الكلمة التي فشلت.

كان عملي هو استبدال ذلك برسالة تحتوي على نتيجة الاختبار ، وتوقع أن تحتوي الرسالة على نتيجة الاختبار المتوقعة (أي صحيحة). إذا فشلت ، يقوم Jest بطباعة الرسالة التي تحتوي على المعلومات الإضافية.

    expect(`${wordType} ${!!words.find((word) => word.wordType === wordType)}`).toEqual(`${wordType} ${true}`);

Jest يطبع هذا ...

expect(received).toEqual(expected)

Difference:

- Expected
+ Received

- 6 true
+ 6 false

... الذي يخبرني أن كلمة نوع كانت 6 عندما فشلت.

أو أكثر قابلية للقراءة شيء مثل ...

    if (!words.find((word) => word.wordType === wordType)) {
      expect(`Didn't find a word with wordType '${wordType}'`).toEqual(null);
    }

cwellsx تحقق من الاختبارات ذات المعلمات باستخدام test.each بهذه الطريقة سيكون كل wordType اختبارًا مستقلاً بعنوان وصفي (بناءً على القيمة)

سيكون هذا مفيدًا بشكل لا يصدق في اختبارات مثل هذا:

test("compare ArrayBufferCursors", () => {
    const orig: ArrayBufferCursor;
    const test: ArrayBufferCursor;

    expect(test.size).toBe(orig.size);

    while (orig.bytes_left) {
        expect(test.u8()).toBe(orig.u8());
    }
});

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

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

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

يذكرني هذا النقاش وظهور jest-expect-message بمشكلة beforeAll في الياسمين ...

قد أكون قد أسيء فهم طلب OP هنا ولكن المشكلة التي كنت أحاول حلها وأحضرتني إلى موضوع المشكلة هذا قد تم حلها فقط باستخدام try / catch وتغليف حول jest.expect . كل ما أردت فعله هو تسجيل جميع الكائنات التي كنت أتوقعها مقابل تلك التي تلقيتها + بعض السجلات الأساسية التي تشرح الأهمية. بالطبع ، يمكن تمديد هذا لفعل ما تريده.

قد يبدو الإصدار الأكثر عمومية من هذا كما يلي:

in some test utility file...

const myExpect = (expectFn, errorCallback) => {
  try {
    expectFn();
  } catch (err) {
    errorCallback();
    throw new Error(err);
  }
};

// in the actual test suite...

const context = { hello: "world", results, expected };
myExpect(
    () => expect(results).toEqual(expected),
    () => console.error("[Error] -- context:", JSON.stringify(context))
);

+1
مرحبًا ، أحب هذه الميزة حقًا أيضًا. سوف تجعل حياتي أسهل بكثير.