Jest: [خطأ] تم العثور على محاكاة يدوية مكررة في أدلة منفصلة

+1

في حالتي ، بعد مسح cacheDirectory / var / folder / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jest وإعادة تثبيت تبعيات npm ، اختفت هذه الرسائل.

هذا هو الرمز المخالف:

https://github.com/facebook/jest/blob/cd8976ec50dbed79cfe07f275052cdd80d466e73/packages/jest-haste-map/src/index.js#L98

لكن يبدو أن السلوك قد يكون مطلوبًا بشكل صريح حيث يوجد اختبار يؤكد ذلك:

https://github.com/facebook/jest/blob/8de90b320c87a0a36d68f6”177620a985df269/packages/jest-haste-map/src/__tests__/__snapshots__/index-test.js.snap#L15

الذي أضيف في:

https://github.com/facebook/jest/commit/cfade282fbbe2737b6dd2cee1cf3da3ee8624512

أتساءل لماذا نستخدم basename بدلاً من المسار بأكمله كمفتاح؟

/ cc flarnie

هذا يعني أن basename s للوحدات يجب أن تكون فريدة عالميًا في المشروع عند استخدام mocks اليدوية. بالنسبة لحالة الاستخدام الخاصة بي ، فهذا يعني أنه لا يمكنني فعل شيء مثل:

import { MyWhatever } from 'models/MyWhatever/schema';
import { MyOtherWhatever } from 'models/MyOtherWhatever/schema';

واستخدم السحابات اليدوية في نفس الوقت. ستراهم Jest حاليًا كلاهما يسخر من schema ويشكو.

على الرغم من أن الحل تافه (s / schema / MyWhateverSchema /) ، يبدو الأمر وكأنه خطأ في إعادة تسمية وإعادة هيكلة الكود غير التجريبي لإسعاد الدعابة 🐞.

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

رائع. قد أجد بعض الوقت غدًا لطهي رقعة ، لكن لا وعود رغم ذلك

cpojer هل هناك سبب معين لهذا السلوك ؟

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

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

cpojer ماذا عن العلم؟ هل تقبل العلاقات العامة التي تمكن / تعطل هذا بعلامة؟

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

cpojer صحيح - أي أجزاء من الدعابة تلامس؟

يتم استدعاء رمز الدقة من jest-runtime: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js وهو في مكان ما في تبعيات jest-Resolution و jest-resolution- .

cpojer شكرا على المؤشرات: +1:

cpojer ماذا عن بعض التجاوزات العامة ، مثل JEST_USE_BASENAME_FOR_CACHING ، لتبديل هذا السلوك؟

على الأقل ، يمكننا الاستمتاع بأسماء ملفات غير فريدة ، ولن يكسر أي شيء في FB.

بالطبع ، إنه حل مؤقت.

أعني ، هذا في بعض /etc/profile أو ~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

(أو بعض الملفات مع env)
وثم

$ jest

أو هذا ، بدون تعديلات ملف env:

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

ما رأيك؟ إنه نوع من الاختراق أم لا بأس؟ :غمزة:

لقد جربت للتو مع ريبو جديد ، باستخدام نسختين من المزاح ( ^15.0.0 و ^17.0.0 ) وعلى الرغم من أن الأخير يعطي التحذير ، فإن الاختبار يتصرف كما هو متوقع.

ColCh لا أعتقد أن المشكلة هنا تتعلق بذاكرة التخزين المؤقت ، ربما يكون الاسم الأنسب هو JEST_USE_BASENAME_FOR_MOCKING .

cpojer إذا كان كود FB يحتوي على قيود على تفرد الأسماء ، فإن استخدام المسار الكامل كمفتاح لخريطة mocks لا ينبغي أن يسبب مشاكل.

هل أنا محق أو هناك شيء لا أراه؟

الحلان اللذان أراهما هما:

• تعديل getMockName لاستيعاب خيار استخدام الاسم الأساسي أو المسار الكامل
• قم بإزالة هذه الوظيفة تمامًا

سيكون من الجيد أن ترى إجابة cpojer عليها

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

أعتقد أنني بخير إذا قررت يا رفاق القيام بأي تغيير جذري في Jest وهو أمر ضروري لتحسين هذا النظام. الاستهزاء اليدوي معيب حقًا ولا يعمل بشكل جيد. شيء واحد نريد القيام به نوعًا ما هو الحد من نطاق "وحدات التسرع" (نظام وحدة FB الداخلية) باستخدام خيار تكوين ، مثل "haste_modules": ['path/a', 'path/b']" وبعد ذلك ننظر فقط إلى وحدات التسرع في تلك المجلدات ، بما في ذلك هذا الاستهزاء الغريب سلوك. إذا أراد أي شخص إجراء هذا التغيير ، فسيكون ذلك رائعًا.

هناك شيء واحد يجب معرفته بعد ذلك ، وهو: إذا كانت جميع الخزائن اليدوية محلية ، مثل خرائط __mocks__/a.js إلى a.js ، فماذا نفعل مع node_module mocks؟ لهذا هناك طريقتان:

• قم بتقديم مجلد __node_modules_mocks__ ولكن هذا أمر قبيح.
• يمكن أن يعمل مجلد المستوى الأعلى __mocks__ كما يظهر من rootDir (جذر المشروع) كمجلد عام.

لذلك للتلخيص:

• دعونا نصلح السحابات اليدوية في Jest!
• دعونا نستعجل وحدات مساحة الاسم ونقصرها على مجلدات معينة / regex أيا كان.
• تأكد من أن سلوك الاستهزاء الحالي لا يزال يعمل مع FB ، حتى لو كان ذلك يعني أنه يتعين علينا إدراج مجلدات معينة في القائمة البيضاء لتسريع العمل (سيبدو الأمر مثل ["<rootDir>"] بالنسبة لنا في الوقت الحالي ، على ما أعتقد)
• اكتشف كيف تظل قادرًا على محاكاة وحدات العقد.

ما رأيك؟

مرتب:

• دعونا نصلح السحابات اليدوية في Jest!

عجل: ابتسم:: تادا:

• دعونا نستعجل وحدات مساحة الاسم ونقصرها على مجلدات معينة / regex أيا كان.
• تأكد من أن سلوك الاستهزاء الحالي لا يزال يعمل مع FB ، حتى لو كان ذلك يعني أنه يتعين علينا إدراج مجلدات معينة في القائمة البيضاء لتسريع العمل (سيبدو الأمر كما يلي]"] بالنسبة لنا في الوقت الحالي ، على ما أعتقد)

لست متأكدًا من فهمي للاحتياجات على عجل.
ما تقصده هو إعطاء إمكانية القول "هذه الوحدات هي وحدات متسرعة"؟
إذا كانت لدينا أربع وحدات: /path_1/a ، /path_1/b ، /path_2/a ، /path_2/c ، والإعداد هو

"haste_modules:" ["/path_1/a", "/path_2/c"]

تم تقييد وجود /path_1/a و /path_1/b فقط في /path_1 ، لذلك /path_2/c صالح ، و /path_2/a يثير خطأ / تحذير.

أود أن أقول ، يمكن أن تكون الأهداف بسهولة ملفات محددة وأدلة كاملة ، حتى مع وجود واحد / مزدوج * .

• اكتشف كيف تظل قادرًا على محاكاة وحدات العقد.

سأحافظ على السلوك الحالي :

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

افكاري:

وحدات التسرع:

أعتقد ، haste_modules جميل ، يناسب تمامًا مثل collectCoverageFrom وخيارات أخرى: مجموعة من الكرات
في هذه الحالة ، إذا كان لديك كل src كوحدات _haste_ ، ودليل واحد فقط غير متسرع:

haste_modules: [
  "src",
  "!src/foo"
]

node_modules

EnoahNetzach ماذا لو كان لدى شخص ما نفس الأسماء لوحدة التطبيق والوحدة من node_modules؟

لجعله يعمل دون تسرع ... حسنًا ، أعتقد أنه يمكن وصفه مثل:

وحدة العقدة المعطاة project/node_modules/react ، سيكون الوهمي داخل project/__node_modules_mocks__/react.js
إذا كان لديك ملف project/react.js ، فاستخدم project/__mocks__/react.js

(بالطبع ، react.js مثال. هنا يمكن أن يكون أي اسم ملف من بين جميع الوحدات ، والتي يمكن تثبيتها من npm )

حقًا ، يعد الاستهزاء بوحدة وحدات وحدات العقدة السخرية؟

أي شخص يسخر من وحدات داخل node_modules في كثير من الأحيان؟

ماذا على وشك التفكير أكثر

كما لاحظت ، بالنسبة للمشاريع الأصلية ، يتعين علينا غالبًا أن نسخر من application modules ونترك الوحدات النمطية من node_modules بدون lodash )

هذا يعني أن لدينا:

• مكون تم إنشاؤه يدويًا لكل مكون غبي (المكون الغبي عبارة عن مكونات تخطيط)
• قائمة طويلة من المكالمات jest.mock في كل ملف اختبار

__ما أريد أن أقوله__: سيكون من الجيد جدًا امتلاك القدرة على محاكاة الوحدات النمطية تلقائيًا في بعض المسارات.

يمكن تنفيذه حول مجموعة هياكل البيانات المعروفة جيدًا في التكوين ، ووحدات التصفية عليها.

سوف أصف ذلك خطوة بخطوة

بالنظر إلى هذا الإدخال التكوين

"autoMockingPaths": [
  "src/components/dumb/**/*.js",
]

وهذا الرمز على src/screens/app.js :

import _ from 'lodash';
import Button from '../../components/dumb/button.js';

// blah blah AppScreen implementation skipped

وكود الاختبار هذا للشاشة بسعر src/screens/__tests__/app-test.js :

import AppScreen from '../app.js';

describe('AppScreen', () => /* testing app screen */);

نأتي إلى هذا الموقف ، في سياق app-test.js :

• AppScreen لا يسخر منه
• lodash لا يسخر منه
• Button ، المطلوب بواسطة AppScreen ، يتعرض للسخرية

... يمكنك الإجابة ، كيف ستلعب مع إدخال التكوين automock ؟

بكل بساطة ، automock: true يعادل:

"autoMockingPaths": [
  "<rootDir>"
]

السخرية من السيارات ... انتظر!

قد يكون مجرد تقديم قيمة خاصة لـ automock ؟ على الأقل لن يكسر تكوينات الأشخاص

على سبيل المثال ، مع إدخال التكوين هذا:

automock: "app"

jest سوف يسخر تلقائيًا من جميع وحدات التطبيق ، ويترك الإصدارات الفعلية للوحدات من node_modules

ما رأيك في التخزين التلقائي للوحدات على مستوى التطبيق ، cpojer ؟ أجد أنه فعال للغاية بالنسبة لحالتي الخاصة.

أتفق تمامًا مع "haste_modules" .

نحن شخصياً لا نستخدم التخزين الآلي بهذا القدر ، لذلك لا يمكنني قول ما هو أفضل ، تخميني الجامح هو أن "autoMockingPaths" var يمكن أن يكون مفيدًا ومرنًا بدرجة كافية.
على العكس من ذلك ، أجد "automock": "app" قاسيًا جدًا ( المزاح معطل بالفعل للتخزين التلقائي افتراضيًا).

يمكن أن يكون __node_modules_mocks__ خيارًا ، أوافق على أن الندرة تعوض عن القبح (في حالتي الخاصة ، نادرًا ما نسخر من node_modules ، وعندما يتعين علينا القيام بذلك ، نستخدم jest.mock(...) ).
التحذير الوحيد هو: ماذا يحدث عندما يكون لديك مجلد متداخل node_modules (على سبيل المثال src/node_modules ) ، هل عليك أن تسخر من وحداته من __node_modules_mocks__ ، نسخة متداخلة من أو عادة مع __mocks__ في نفس الموقع؟

قد يكون مجرد رمي ، إذا كان لدى شخص ما نفس اسم الوحدة في node_modules و app modules

على سبيل المثال

app/express.js كوحدة تطبيقات (ربما أقوم بلعبة قطار)
و app/node_modules/express كخادم ويب من npm
throw new Error("can't mock express.js file - it duplicates one from node_modules")

في هذه الحالة ، يمكن استخدام __mocks__ مقابل node_modules ، لكن يجب على المطورين إعادة تسمية الوحدات النمطية الخاصة بهذه التصادمات

ناه ... هذا أبشع من __node_modules_mocks__ ، أليس كذلك؟

ما قصدته هو: ماذا لو كان لديك وحدة npm install ed x والإصدارات الأحدث ، حدد وحدة نمطية x في مجلد node_modules متداخل ؟

عادة ما يتم التعامل مع تضارب التسمية في العقدة من خلال تفضيل الأقرب ، لكني لا أعرف كيف يتم ذلك على عجل.

أنا أتحدث عن هذا لأن مشاريع مثل Create React App تستخدمه أو ستفعله في المستقبل القريب.

على الجانب علما،cpojer هذا القضية المتعلقة بطريقة أو بأخرى؟

دعنا نركز على تغيير طريقة عمل التسرع (القائمة البيضاء / القائمة السوداء بدلاً من التشغيل افتراضيًا). أعتقد أنني أفضل الحفاظ على أن <rootDir>/__mocks__ يجب أن يكون الافتراضي لوحدات وحدات العقدة. يمكننا أن نجعل هذا خيار تكوين أيضًا: "globalMocks" الذي يتم تعيينه افتراضيًا على <rootDir>/__mocks__ . هل هناك من يرغب في العمل على هذا؟

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

يمكنني العمل في العلاقات العامة هذا الأحد ، أنا حر نوعًا ما

cpojer فقط للتلخيص - أنشئ إدخال تهيئة globalMocks بقيمة افتراضية <rootDir>/__mocks__ . ينظم هذا الخيار استخدام node-haste في المزاح بتحديد المسار؟ أم أنها ستكون مجموعة من المسارات؟

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

من: Max Sysoev [email protected]
تاريخ الإرسال: الجمعة 9 ديسمبر 2016 الساعة 8:18:44 صباحًا
إلى: facebook / jest
نسخة إلى: كريستوف بوجير ؛ أشير
الموضوع: Re: [facebook / jest] [خطأ] تم العثور على محاكاة يدوية مكررة في أدلة منفصلة (# 2070)

يمكنني العمل في العلاقات العامة هذا الأحد ، أنا حر نوعًا ما

cpojer https://github.com/cpojer فقط للتلخيص - قم بإنشاء إدخال تكوين globalMocks بقيمة افتراضية/ __ mocks__. ينظم هذا الخيار استخدام تسرع العقدة ضمن الدعابة عن طريق تحديد المسار؟ أم أنها ستكون مجموعة من المسارات؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 ، أو كتم صوت سلسلة المحادثات https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3WkAzks2JQZ .

عذرًا ، لقد تعطلت محطة العمل الخاصة بي ، ويبدو أنه لا توجد طريقة لتشغيلها في غضون شهرين (1-2 شهر). حتى أنني فقدت مشروعي في هذا العلاقات العامة :( لذا ، آسف لتحمل المسؤوليات.

ماذا عن مجرد خيار تكوين لتغيير سلوك getMockName ؟

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

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

{ 'aws-sdk': '/Users/project/__mocks__/aws-sdk.js',
  'slack': '/Users/project/__mocks__/slack.js',
  '/Users/project/db/index': '/Users/project/db/__mocks__/index.js',
  '/Users/project/slack/index': '/Users/projects/slack/__mocks__/index.js' }

require('aws-sdk') يجب أن يحل إلى /Users/project/__mocks__/aws-sdk.js هذا محاكاة لـ node_module .

يجب حل require('./db') (أو أي مسار إلى db ) إلى: /Users/project/db/__mocks__/index.js .

كان فهمي لطريقة إعداد mocks اليدوية jest (وربما يجب أن يكون هناك المزيد من الوثائق إذا تم استخدام شيء مثل أعلاه) هو أنه يجب أن يكونوا أقرب ما يكون إلى الملف الذي يتم السخرية منه قدر الإمكان داخل دليل __mocks__ .

يتم تعريف النماذج اليدوية عن طريق كتابة وحدة في دليل فرعي __mocks __ / بجوار الوحدة مباشرةً. (https://facebook.github.io/jest/docs/manual-mocks.html)

بالنظر إلى ذلك ، فإن السلوك أعلاه هو الأكثر منطقية بالنسبة لي.

أفكار؟

هذا تمريرة أولية عند تنفيذ شيء مثل ما ورد أعلاه: https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-Resolution

إنه يكسر غالبية اختبارات وحدة الدعابة لأنه لم يعد يسمح بأشكال "مسماة" خالصة مثل ما يلي: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

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

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

لا يمكننا كسر السلوك الحالي لأننا نعتمد عليه بشدة في Facebook.

cpojer أوافق. لم أفهم هذا التعليق حقًا بعد قراءة الكود: https://github.com/facebook/jest/issues/2070#issuecomment -265027510. ربما يمكننا دعم القائمة البيضاء لقائمة من الدلائل التي ستحل على السلوك الحالي؟

ماذا عن خيارين تكوين جديدين:

• fullPathMockResolution (افتراضيًا إلى false للاحتفاظ بالسلوك الحالي)
  مرفق مع:
• namedMockDirectories : إذا تم تمكين fullPathMockResolution ، فسيتم حل أي أدلة داخل هذا المصفوفة بالسلوك الحالي. بالنسبة لحالة استخدام FB ، سيكون هذا فقط [<rootDir>] كما ذكرت أعلاه.

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

ccvoideanvalue قد يكون هذا شيئًا يجب عليك التفكير فيه (دليل مساحة الاسم يسخر كجزء من تنفيذ التسرع الجديد).

+1 ، هل هناك طريقة لإصلاح ذلك؟

+1

أي تحديثات حول كيفية حل هذه المشكلة؟ قد يكون هذا مؤلمًا حقًا إذا اتبعت هيكلًا مثل هذا:

project/
├── models
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/
├── challenges
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/

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

في صحتك،
دومينيك

cpojer أي تحديثات هنا يا شباب؟ ايوجد اي عمل في هذه المنطقه؟

القليل من الحل بالنسبة لي هو السخرية من الوحدات التي تتطلب

jest.mock('models/index', () => require('models/index/_mocks_/index'));

أعدت تسمية اسم المجلد __mocks__ إلى _mocks_ حتى لا تلتقط الدعابة الملفات.

في أحد الأيام عندما يعمل هذا ، سأعيد تسمية _mocks_ إلى __mocks__ وإزالة الجزء المطلوب من jest.mock

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

+1 محبط للغاية لرؤية هذه التحذيرات. لا يمكن أن تنتظر الإصلاح.

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

إذا كان لدي jest.mock ('src / utils / history') ، فإنه يسخر بشكل غير صحيح من node_module 'history'.

https://github.com/cwmoo740/jest-manual-mocks-node-modules

رفاق أي تحديث؟

masoudcs أعتقد أن هذا تخلص من التحذير:

package.json

"jest": {
  /* other settings ... */
  "modulePathIgnorePatterns": ["<rootDir>/node_modules/react-native/Libraries/Core/__mocks__"]
}

أضف المجلدات "المكررة" في المصفوفة modulePathIgnorePatterns وسيختفي التحذير

شكرا @ برونولم

اذن هو مجرد تحذير صحيح ؟!
أريد فقط التأكد من أن هذا لن يتسبب في حدوث شيء سيء ، مثل الاستهزاء بـ index.js في أدلة متعددة:
src/app/modules/module1/__mocks__/index.js و src/app/modules/module2/__mocks__/index.js

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

لذلك أعتقد أنه من الجيد إخبارها بالتجاهل ، لم تكن تستخدمها على أي حال.

نعم كما قلت ولم نواجه أية مشاكل حتى الآن.
نأمل أن تفعل ما يجب أن تفعله! :)
شكر

لقد جربت ما اقترحه هذان الالتزامان الأخيران ولكن لم أزل التحذير.

jest.mock('dir/index', () => require('dir/__mocks_/index'));

أشاهد هذا التحذير لأنني أستخدم GitBook (الدليل ./_book ) ، على الرغم من وجود testPathIgnorePatterns: ['/_book/', ...otherStuff] في التهيئة. من خلال تخطي هذه المشكلة ، لا أرى حلاً بديلاً واضحًا. أريد فقط التوقف عن رؤية التحذيرات - سأكون ممتنًا لأي مساعدة.

+1

أي تحديث على هذا؟

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

jest.mock('models/index', () => require('models/index/_mocks_/index'));

تبدو بنية الدليل الخاصة بنا هي نفسها كما في dkundel المشار إليها هنا https://github.com/facebook/jest/issues/2070#issuecomment -301332202 مع النماذج والمكونات في مساحات الأسماء الخاصة بها حيث يكون index.js هو الافتراضي تصدير.

يُفضل عدم إسكات التحذيرات أو إلقاء جميع النماذج في دليل مسطح. بعض نماذجنا متداخلة بشدة ، ومن المحتمل أن يبدو الحل البديل المقترح
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
في هيكلنا.

أي كلمة؟

karomancer لقد قدمت PR # 6037 والذي سيتيح لك استخدام التكوين لإزالة التحذيرات. حتى الآن ، لم يتم دمجه ؛ أنا في انتظار الرد من المساهمين.

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

في package.json

{
  "jest": {
    "setupFiles": [
      "<rootDir>/test.mocks.ts"
    ]
  }
}

/* test.mocks.ts */

// modules mocked before every test
// use `jest.unmock(...)` to undo for any single test case
const mockedModules = [
    "./path/to/module1/index.ts",
    "./path/to/module2/index.ts",
];

mockedModules.forEach((path) => {
    const mockPath = path.replace(/\.ts$/g, ".mock.ts");
    jest.mock(path, () => require(mockPath));
});

سيسمح لك هذا بالسخرية من anything.ts بإنشاء شقيق anything.mock.ts وإضافة المسار إلى الأصل في مصفوفة mockedModules ذات المستوى الأعلى test.mocks .

لماذا تم وضع علامة على هذه المشكلة على أنها تحسين؟

يبدو هذا عمل بالنسبة لي. في jest.config.js:

module.exports = {
  // ...
  modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]
};

لست متأكدًا من نطاق أو تأثير هذا التغيير ، لأن لدي مشروعًا صغيرًا.

@ amccloud شكرا! هذا حل مشكلتي! التفاصيل أدناه.

لدي وحدة helpers في الدليل الجذر لمشروعي. يقوم المساعد بتصدير الوظيفة parseNodeFromString .
لقد أنشأت في ملف وحدة نمطية أخرى محلية helpers . ثم سخرت منه في أحد اختباراتي. وبدأت جميع الاختبارات التي تستخدم الدالة parseNodeFromString بالفشل مع الخطأ التالي:

FAIL  src/some_dir/bla/tests/SomeClass.test.js
  ● Test suite failed to run

    TypeError: (0 , _helpers.parseNodeFromString) is not a function

ماذا عن هذه القضية؟ يبدو أن حل amccloud صحيح.

modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]

يعمل هذا الحل على الرغم من أنه جعل نماذج المستوى الأعلى لوحدات العقدة تفشل. لذا قمت بتغييره حتى لا أتجاهل مجلد __mock__ الجذر الخاص بي بـ: "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"], . لا يزال من الغريب أن mocks ليست فريدة فقط بناءً على المسار الكامل من الجذر. من الشائع جدًا أن يكون لديك: users/helper.js & posts/helper.js . يستغرق التحذير بعض المساحة ، ولا أريد إخفاء التحذيرات الفعلية تمامًا.

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

في حالتي ، تم نسخ النموذج الوهمي إلى Dist dir مع كل بناء.

يبدو أن هذه مشكلة تتعلق بعدم قدرة الكتابة المطبوعة على استبعاد المسارات / الأنماط التي تنتمي إلى بنية dir أعمق. لا تزال مشكلة مع "[email protected]".

لإصلاح ذلك ، بدأت بتنظيف Dist dir الخاص بي باستخدام "rimraf dist" قبل كل تشغيل تجريبي.

"test:unit": "npm run clean && stencil test --spec --snapshot",

أعرف أنه اختراق ، لكنه يعمل.

مرحبًا ، لقد حللت هذا هنا ما حدث ، وربما يمكن أن يساعدك في تكرار ذلك.

ثلاثة حلول أو سيناريوهات:

1 ، كنت أقوم بتحرير تطبيقي على محرر النصوص الخاص بي مرتين بمعنى ، كنت أقوم بتشغيل تثبيت / تحديث pod وتشغيل نظام تشغيل ios الأصلي من نافذتين مختلفتين. وحصلت على هذا الخطأ ، حاولت البحث عن الملفات المكررة في Xcode وعلى تطبيقي لكن لم أجد أيًا منها. لذلك ، قمت ببساطة بحذف التطبيق من المحاكي وأعدت تشغيل نظام التشغيل التفاعلي الذي يعمل بنظام التشغيل ios ، وقد نجح الأمر ، واتضح أنه تم تكرار وحدتين node_modules على هذا النحو: node_modules و node_modules0 في ملف scr الخاص بي

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

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

لا شيء حتى الآن؟ لا يمكن استخدام modulePathIgnorePatterns في CRA

3 سنوات و 10 شهور

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