Jest: دليل لقطات قابل للتكوين للاختبارات ذات الموقع المشترك

يتم دمج اللقطات مع الاختبارات وهي بالتأكيد ليست مخصصة لقراءة الجهاز. من المفترض أن تتم مراجعتها من قبل البشر ، مؤلفي الاختبار ومراجعي الكود.

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

شكرا على الرد السريع!

أفهم أن اللقطات من المفترض قراءتها ومراجعتها. يبدو الأمر فوضويًا بعض الشيء أن يكون لديك __snapshots__ متناثرة في جميع أنحاء قاعدة التعليمات البرمجية عندما أرغب في إجراء اختبارات مع المكونات. قد يأتي هذا أيضًا من نمط تجميع المكونات حسب الوظيفة ، بدلاً من وجود دليل components (مثل user/Profile.js و layout/Nav.js ).

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

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

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

أنا لا أفهم حقًا ما تعنيه. يتم تجميع اللقطات مع الاختبارات وهناك تعيين 1: 1 بين testfilename.js و __snapshots__/testfilename.js.snap ؟

يبدو دليلي حاليًا مثل هذا قليلاً:

js/
  user/
    __snapshots__/
      Avatar.test.js.snap
      Profile.test.js.snap
    Avatar.js
    Avatar.test.js
    Profile.js
    Profile.test.js
  layout/
    __snapshots__/
      App.test.js.snap
      Nav.test.js.snap
    App.js
    App.test.js
    Nav.js
    Nav.test.js

إن __snapshots__ بهذه الطريقة _ فوضى بعض الشيء بالنسبة لي (لكن هذا قد يكون أنا فقط).

كبديل ، كان تفكيري أن بنية دليل مثل هذه قد يكون من الأسهل فهمها / تمشيطها من خلال:

js/
  __snapshots__/
    user/
      Avatar.test.js.snap
      Profile.test.js.snap
    layout/
      App.test.js.snap
      Nav.test.js.snap
  user/
    Avatar.js
    Avatar.test.js
    Profile.js
    Profile.test.js
  layout/
    App.js
    App.test.js
    Nav.js
    Nav.test.js

لكن هذا عكس تجميع ملفات اللقطات مع اختباراتهم ، أليس كذلك؟

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

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

يمكننا أيضًا المساعدة في قناة الخلاف لدينا ويسعدنا مراجعة الكود ، بالطبع :)

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

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

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

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

exports.resolveSnapshotFile = testPath => snapshotFilePath;
exports.resolveTestFile = snapshotFilePath => testPath;

وبهذه الطريقة يمكننا استدعاء هذه الطرق لحل مسار اللقطة من مسار الاختبار والعكس بالعكس وسيمكن استخدامها للحفاظ على اتساق ملفات اللقطة.

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

لدي نفس مشكلة # 1653.

نهج المعالج ليس جيدًا في حالة

1. TypeScript و IntelliJ IDEA.

   لأن IntelliJ IDEA يحتوي على مترجم TS مدمج سريع جدًا. لذلك ، أثناء التحرير لا يوجد إخراج مترجم. وتضيف مهمة "Compile TypeScript" لتشغيل التكوين - سيتم تفريغ الإخراج من الذاكرة إلى FS عند التشغيل. لا حاجة لاستخدام معالج وقت التشغيل البطيء (لأن ts يجب أن تعمل على المشروع بأكمله ، - على عكس بابل).

2. TypeScript على خادم CI.
   لأنك على خادم CI في أي حال تقوم بتجميع جميع المصادر قبل التشغيل التجريبي - مرة أخرى لأن TS / tslint يعمل على المشروع بأكمله ، وليس في ملف فردي.

حسنًا ، كحل بديل ، يمكن إضافة out/__snapshots__ إلى VCS.

👀
بعد هذا للعمل عليه في المستقبل القريب

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

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

نعم ، أعتقد أنه سيكون من الجيد الحصول على هذه الميزة.
لست سعيدًا بنسبة 100٪ بلقطاتي في جميع أنحاء المشروع. :(

ولا أحب نسخ بنية المشروع في مجلد __test__ ...

+1 ، أود أيضًا نقل جميع اللقطات إلى مجلد واحد.

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

ثم ننقل هذه المناقشة هناك.

عظيم!

اسمحوا لي أن أعرف إذا كنت أستطيع مساعدتك. كنت أفكر في التعقيد.

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

أخبرني cpojer أن ljharb مهتم بهذه الميزة أيضًا.

lucasfelicianoluispuig أي تقدم على ذلك؟ هل تريد بعض المساعدة في شيء ما؟

لم أحاول ...

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

أنا شخصيًا في الدليل لكل معسكر مكون ، وأجري اختبارات الوحدة الخاصة بي كأخوة لكود المكون باستخدام اصطلاح component.test.js.

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

يبدو أن السحر يحدث هنا .. https://github.com/facebook/jest/blob/master/packages/jest-snapshot/src/utils.js#L96

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

على أي حال ، فإن فتح الدعم لنمط * .test.js ، ولكن عدم دعم نفس بنية الأشقاء لملفات اللقطة يبدو وكأنه نوع من عدم الاتساق.

مرحبا،

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

إذا كنت تستخدم مجلد __testing__ ، فعليك إدخال كل شيء في نفس المجلد. ولكن إذا كان عملك على proyecta مختلفًا ، فمن الأسوأ نقل المكونات لأنك يجب أن تنسخ المكون والاختبار في مجلد مختلف.

ولكن إذا استخدمنا الاختبار مع المكون ، فسيصبح ممتلئًا بمجلدات _snapshot_.

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

حصلت على cuestión. هل من الممكن أن تستخدم jest نفس ملف الاختبار لتخزين اللقطات؟ سيكون هذا رائعًا ويلبي الاتجاهين.

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

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

الأسلوب الذي سرعان ما يصبح هو القاعدة ، هو وضع ملفات اختبار الوحدة كأشقاء للرمز قيد الاختبار. هذا هو سبب دعم jest الآن لملفات * .test.js.

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

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

أنا جديد إلى حد ما على عالم JS لأكون صادقًا (لدي 20 عامًا من تطوير JVM xp) ، وأشعر أن "حرب المعايير" لا تزال مستمرة في هذا النظام البيئي. على أي حال ، فإن مكتبة الاختبار ليست حقًا ساحة معركة مناسبة لهذا النوع من الأشياء في رأيي. إذا كانت هناك أداة مثل ، "create-reaction-app" ، لتهيئة الدعابة بطريقة متعصبة ستكون وجعتي أكثر ليونة ، لأن هذه الأنواع من تطبيقات القوالب هي أماكن معقولة لمحاربة حرب المعايير. الأشخاص الذين يستخدمون هذه الأشياء يوافقون بطريقة ما على وجود رأي شخص آخر حول الهيكل المطبق على مشروعهم. ما زلت قد أشكو من أنه سيكون من الجيد أن أتجاوزها (بدون "إخراج") ، لكني أشعر أن القضية ستكون أضعف.

... لكن مكتبة الاختبار التي تطبق رأيها في بنية git repo ... لا. لا يمكن أن تقف وراء ذلك حقا.

@ قاعة

أنا أتفق معك. أفضل ممارسة هي الاحتفاظ بملف اللقطة مع ملف الاختبار.

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

هذا رأيي أيضًا.

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

نظرًا لأن jest لديه القدرة على التهيئة من ملف package.json (https://facebook.github.io/jest/docs/configuration.html) ، فإن ما أفعله هو إضافة مفتاح تهيئة جديد يسمى "snapshotDirectory "، هذا يسمح بتكوين هذا. شخصيًا ، سأكون سعيدًا بالتعبير عن هذه القيمة بالنسبة للاختبار (لذا فإن السلوك الذي نصفه سيكون قابلاً للتكوين بتحديد إما "." أو "") ، وترك القيمة الحالية على أنها القيمة الافتراضية.

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

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

ربما لا يكون ذلك ممكنًا ، لكنه سيكون رائعًا.

أنا حقا لا أحب هذا السلوك. أنا أفضل filename.test.js.snapshot

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

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

أعتقد (أكثر أو أقل) أن الشيء "filename.test.js.snapshot" هو ما أتحدث عنه على أي حال. بشكل أساسي ، ما عليك سوى كتابة نفس الملفات التي تتم كتابتها الآن ، كأشقاء لملفات الاختبار بدلاً من الدليل الفرعي __snapshots__.

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

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

شكر

wesleyhall يرجى تقديم العلاقات العامة إلى الدعابة إذا كتبت الرمز ؛ سيساعد المناقشة في حالة وجود علاقات عامة تم اختبارها ونظيفة تسمح بتكوين موقع اللقطات.

ljharb

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

محرك قضية اللقطة بأكملها هو فئة SnapshotState المحددة في State.js داخل حزمة jest-snapshot. إذا نظرت إلى المُنشئ (https://github.com/facebook/jest/blob/master/packages/jest-snapshot/src/State.js#L48) ، فسترى أنه تم تعيين سمة مسار اللقطة من حجة منشئ. فقط إذا كانت "خطأ" ، فإنها تنتقل إلى وظيفة "getSnapshotPath ()" حيث يتم تطبيق الترميز الثابت للدليل __snapshots__. إذا تم تمرير مسار إلى المنشئ ، فيبدو أنه سيستخدم ذلك بدلاً من ذلك.

يتم إنشاء الكائن بواسطة وظيفة initializeSnapshotState في ملف jest-snapshot index.js (https://github.com/facebook/jest/blob/master/packages/jest-snapshot/src/index.js#L58) ، والتي يأخذ موقع اللقطة كوسيطة ويمررها إلى المنشئ.

يتم تصدير هذه الوظيفة ، ويبدو أنه يتم استدعاؤها فقط ضمن حزمة jest-jasmine2 ، داخل ملف يسمى setup-jest-globals.js (https://github.com/facebook/jest/blob/master/packages/jest- jasmine2 / src / setup-jest-globals.js # L115).

لاحظ أن الوسيطة الثالثة هناك سلسلة فارغة. هذا هو مسار اللقطة ، لذلك يتم تمرير هذا بشكل أساسي على طول الطريق إلى مُنشئ SnapshotState ، وبما أن السلسلة الفارغة هي "false" ، يتم استدعاء "getSnapshotPath ()" في كل مرة.

هذه الوظيفة التي تم تصديرها في setup-jest-globals.js لديها حق الوصول إلى كائن التكوين كوسيطة ، لذلك أتخيل ، قد يكون الأمر مجرد استبدال السلسلة الفارغة بشيء مثل ، 'config.snapshotDirectory'. تتمتع الوظيفة أيضًا بإمكانية الوصول إلى testPath (المسار إلى الملف الذي يتم اختباره) ، لذلك يجب أن يكون من الممكن دعم مسارات اللقطة المتعلقة بموقع الاختبار باستخدام "\

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

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

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

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

wesleyhall شكرا! (يجب أن يوفر لك http://nvm.sh و nvm install node نظريًا بيئة عاملة إلا إذا كنت تستخدم نظام Windows)

ljharb :) حسنًا ، لست

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

ربما تكون المشكلة الأكبر هي التعقيدات الموجودة في وحدتي jest-cli و jest-config. تم ذكر خيارات التكوين والإشارة إليها في أماكن عديدة. يعثر IDE الخاص بي على 6 ملفات مصدر مختلفة على الأقل تحتوي على كائنات باستخدام مفتاح snapshotSerializers. لم يتم التعليق على هذه الملفات ، لذا من الصعب تحديد الغرض من كل منها وما أحتاج إلى تغييره لدعم خيار تكوين جديد. سأضطر إلى الغوص بعمق قليلاً ، لكن سأواجه صدعًا عندما تسنح لي الفرصة.

لا تدع عدد النتائج يخيفك عندما تبحث عن مفتاح تهيئة مثل هذا. من المحتمل أن تحصل على نتائج للمجلدين src و build ، بالإضافة إلى أنواع المفتاح.

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

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

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

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

لا ، من فضلك استمر بكل الوسائل. يمكنني إلقاء نظرة على العلاقات العامة الخاصة بك ومعرفة مدى قرب (أو بعيد) كنت :).

لم أقم حقًا بالبحث كثيرًا في عناصر التدفق بالكامل حتى الآن ، لذلك هناك بعض الثغرات في تجربتي هنا. لقد بدأ بالفعل أي عمل جاد لـ JS في يناير من هذا العام ، لذا نعم ، n00b :). 20 عامًا في JVM. كل شيء مجرد أصفار وآحاد في نهاية اليوم ؛).

قد ألتزم وأتعلم من حشد السحرة المتجمعين.

شكرا لمساعدتك.

ليس هناك أى مشكلة!

لقد كنت أعمل مع Reason مؤخرًا وبدأت في كتابة اختبارات اللقطة لمكوناتي ، ولكن المشكلة كانت عندما يتم تحويل ملفات .re إلى .js يتم إخراجها في دليل آخر. لذلك ينتهي الأمر بلقطاتي في دليل موجود في .gitignore لأنه تم إنشاؤها لاختبار ملفات .js .

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

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

ممتاز. شكرا مرة اخرى.

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

إذا قمت باستعادة:

this._snapshotPath = snapshotPath || getSnapshotPath(testPath);

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

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

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

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

يمكن أيضًا تغيير:

path.join(snapshotPath || path.dirname(testPath), '__snapshots__')

من وظيفة getSnapshotPath إلى شيء مثل:

snapshotPath || path.join(path.dirname(testPath), '__snapshots__')

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

لدي هيكل دليل يشبه هذا حاليًا:

app/
    components/
        Foo/
            __snapshots__
                component.test.js.snap
                reducer.test.js.snap
            component.js
            component.test.js
            reducer.js
            reducer.test.js
        Bar/
            __snapshots__
                component.test.js.snap
                reducer.test.js.snap
            component.js
            component.test.js
            reducer.js
            reducer.test.js

إذا كان وضعها في مجلد جذر واحد __snapshots__ غير وارد ، فهل سيكون شيء مثل أدناه مقبولاً أكثر؟

app/
    components/
        Foo/
            component.js
            component.test.js
            component.test.js.snap
            reducer.js
            reducer.test.js
            reducer.test.js.snap
        Bar/
            component.js
            component.test.js
            component.test.js.snap
            reducer.js
            reducer.test.js
            reducer.test.js.snap

يعتمد تطبيقنا على المكون الإضافي / الميزة ، لذا فإن كل مكون موجود في دليل منفصل ، والذي يحتوي على العديد من الملفات المتعلقة به.

lukescott لدينا نسخة معدلة نستخدمها والتي تضع اللقطات بجوار الاختبار كما يقول تعليقك ، ببساطة عن طريق إزالة __snapshots__ من هذا السطر: https://github.com/facebook/jest/blob/master/packages /jest-snapshot/src/utils.js#L94

تعجبني فكرة

• component.js
• component.test.js
• component.snap.js

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

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

app/
    components/
        Foo/
            spec/
                __snapshots__/
                    component.test.js.snap
                    reducer.test.js.snap
                component.test.js
                reducer.test.js
            component.js
            reducer.js

cpojer هل

من خلال إضافة خيار تهيئة حل اللقطات التي تشير إلى وحدة ذات وظيفتين:

exports.resolveSnapshotFile = testPath => snapshotFilePath;
exports.resolveTestFile = snapshotFilePath => testPath;

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

import {replacePathSepForRegex} from 'jest-regex-util';

const snapshotDirRegex = new RegExp(replacePathSepForRegex('/__snapshots__/'));
const snapshotFileRegex = new RegExp(
  replacePathSepForRegex('__snapshots__/(.*).snap'),
);
const isSnapshotPath = (path: string): boolean =>
!!path.match(snapshotDirRegex);

يمكننا الحصول على snapshotFileRegex & snapshotFileRegex من تهيئة jest.

aminroosta أحب أن أرى تلك العلاقات العامة ؛ سيكون من الرائع فتحه وفي حالة جيدة حيث يمكننا الدفاع عن المزاح لدمجه!

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

آمل أن تبدو هذه حالة استخدام حقيقية لدعمها. أستطيع أن أرى أنها حالة نادرة ، لكنني أعتقد أنها مرتبطة بقضايا أخرى أحضرها الناس هنا. شكر!

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

joshduck هم لا يريدون رؤية ↑

cpojer Disagree ، بالنسبة لمشاريع

هذا أمر مؤسف حقًا إذا كنت تستخدم إعدادًا حيث لديك ملفات مصدر (مثل TypeScript) يتم إيداعها وإخراج الملفات (مثل JS المقابلة) التي لم يتم إيداعها. تنتهي ملفات اللقطة في الوضع العادي- .gitignore 'd الدليل.

الكثير من الفوضى بدون هذه الوظيفة ...

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

لا أحب فكرة وجود دليل __snapshots__ مع كل اختبار أيضًا ، وأنا أفضل أن يكون لدي خيار لوضعهم جميعًا في دليل واحد على سبيل المثال في المستوى الأعلى. بالنسبة لي ، إنه مجرد شيء مرئي ومئات IMHO من __snapshots__ dirs المتناثرة على شجرة الملفات تبدو فوضوية حقًا. لحسن الحظ ، هناك حل بسيط لهذا في VS Code - ما عليك سوى استبعاد دليل __snapshots__ من مستكشف الملفات في إعداداتك مثل هذا:

    "files.exclude": {
        "**/__snapshots__": true
    }

بهذه الطريقة سيتم إخفاء دليل __snapshots__ في مستكشف الملفات في رمز VS الخاص بك. أعتقد أن هذا ممكن أيضًا في IDEs لـ Jetbrains.

قضيت بضع ساعات في البحث في هذا الأمر ، وطرح PR # 6143 بناءً على اقتراح سابق لأي شخص مهتم.

يبدو أنك تتحرك للأمام مع هذاviddo. شكرًا لعملك على هذا ، أود حقًا أن أرى هذا مدمجًا.

شكراviddo! 😍

لقد هبط هذا وسيكون متاحًا في Jest 24. وهو متاح حاليًا عن طريق تثبيت jest@beta

في حال وجد الآخرون أنه مفيد ، فإليك محتويات اقتراح assertchris الذي قدمته على snapshotResolver.js :

// https://jestjs.io/docs/en/configuration.html#snapshotresolver-string
module.exports = {
  testPathForConsistencyCheck: 'some/example.test.js',

  resolveSnapshotPath: (testPath, snapshotExtension) =>
    testPath.replace(/\.test\.([tj]sx?)/, `${snapshotExtension}.$1`),

  resolveTestPath: (snapshotFilePath, snapshotExtension) =>
    snapshotFilePath.replace(snapshotExtension, '.test'),
}

وينتج عنه

component.ts
component.test.ts
component.snap.ts

إذا كنت تريد وضع ملفات الاختبار ( *.test.js ) بجوار المكونات ذات الصلة ولكن ضع اللقطات في دليل واحد ( __snapshots__ ) ، فيمكنك القيام بذلك.

// jest.config.js
module.exports = {
... ...
snapshotResolver: './ __snapshots__ /snapshotResolver.js' ،
... ...
}

// snapshotResolver.js

module.exports = {
حل: (testPath ، snapshotExtension) =>
testPath
.replace (/. test. ([tj] sx؟) /، '.test' + snapshotExtension)
.replace ( /src([/\\]components ) /، '__snapshots__' )،

solutionTestPath: (snapshotFilePath ، snapshotExtension) =>
snapshotFilePath.replace (snapshotExtension، '.js'). replace ( '__snapshots__' ، 'src / مكونات') ،

testPathForConsistencyCheck: 'src / component / some.test.js'،
}