Jest: Настраиваемый каталог моментальных снимков для совместных тестов

Моментальные снимки размещены вместе с тестами, и они определенно не предназначены для машиночитаемости. Они предназначены для проверки людьми, как авторами теста, так и обозревателями кода.

Jest также гарантирует, что в системе никогда не будет устаревших снимков. Это означает, что нам обоим нужен способ сопоставления снимка состояния с соответствующим тестом и обратно. Это кажется сложным для настройки с помощью строковых значений в конфигурации JSON :(

Спасибо за быстрый ответ!

Я понимаю, что снимки предназначены для чтения и проверки. Просто кажется немного беспорядочным иметь __snapshots__ разбросанное по всей кодовой базе, когда я хочу, чтобы тесты были размещены вместе с компонентами. Это также может происходить из-за шаблона группировки компонентов по функциональности, а не из-за наличия каталога components (например, user/Profile.js и layout/Nav.js ).

А пока я только начал переносить тесты в __tests__ чтобы собрать __snapshots__ в одном месте, но это не мой идеал.

Я также понимаю, что это немного сложно настроить. Моя мысль заключалась в том, чтобы определить некий каталог верхнего уровня для __snapshots__ и сделать так, чтобы структура каталогов в нем соответствовала пути к компоненту с этого верхнего уровня.

Возможно, это просто мне кажется неприятным. Любопытно услышать от других, что тесты размещают вместе с компонентами и имеют несколько каталогов компонентов.

Я не совсем понимаю, что вы имеете в виду. Моментальные снимки расположены вместе с тестами, и между 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__ , которые созданы / разбросаны по всей кодовой базе (по крайней мере, так, как я решил организовать свои компоненты).

Я не религиозно против этого, если вы хотите проделать всю работу, необходимую для поддержки этого, найти способ сделать это поддерживаемым и хорошо протестировать.

Мы также можем помочь на нашем канале Discord и, конечно же, будем рады проверить код :)

Я думаю, что мой главный аргумент заключается в том, что снимки создаются автоматически и не предназначены для изменения вручную или импорта непосредственно в кодовую базу. Поэтому было бы неправильно смешивать их в коде, который вы активно редактируете / поддерживаете / импортируете.

Я тоже не особо женат на этой идее :) Просто хотел предложить ее, чтобы узнать, что думают другие. Если я не одинок в этом, я могу найти время, чтобы смоделировать PR и посмотреть, как он может выглядеть.

Я уверен, что вы найдете много людей, которые разделяют ваше мнение. Для людей тестирование похоже на религию, и я счастлив поддерживать все виды этого, если они хорошо интегрируются с Jest и хорошо протестированы.

Это то, в чем нам понадобится помощь сообщества. Я думаю, что хороший способ поддержать это - добавить параметр конфигурации resolveSnapshots который указывает на модуль с двумя функциями:

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

таким образом мы можем вызвать эти методы для разрешения пути к моментальному снимку из тестового пути и наоборот, и это позволит использовать для сохранения согласованности файлов моментальных снимков.

Я закрою это из-за бездействия. Если кто-то захочет поработать над этим, я с радостью открою его и сделаю обзор PR :)

У меня та же проблема, что и # 1653.

препроцессорный подход не годится в случае

1. TypeScript и IntelliJ IDEA.

   Потому что IntelliJ IDEA имеет встроенный очень быстрый компилятор TS. Итак, при редактировании компилятор не выводит данные. И вы добавляете задачу «Скомпилировать TypeScript» для запуска конфигурации - вывод будет выгружен из памяти в FS при запуске. Нет необходимости использовать медленный (потому что ts должен работать со всем проектом - в отличие от babel) препроцессор времени выполнения.

2. TypeScript на CI-сервере.
   Потому что на CI-сервере вы в любом случае компилируете все исходники перед тестовым запуском - опять же, потому что TS / tslint работает со всем проектом, а не с отдельным файлом.

Что ж, в качестве обходного пути в VCS можно добавить out/__snapshots__ .

👀
После этого поработаем над этим в ближайшем будущем

На самом деле на данный момент я не думаю, что хочу поддерживать эту функцию. Это добавляет ненужной сложности и почти не имеет ценности.

Так. Как это закончилось ?. Мне очень нравится иметь каждый тест со своим компонентом. Но я бы предпочел хранить весь файл моментального снимка в отдельной папке, а не вокруг кода.

Да, я думаю, было бы хорошо иметь эту функцию.
Я не на 100% доволен своими снимками всего проекта. :(

И мне тоже не нравится тиражировать структуру проекта в папке __test__ ...

+1, я бы тоже хотел, чтобы все снимки переместились в одну папку.

Круто, попробую поработать на выходных и предложить пиар.

Затем переносим это обсуждение туда.

Большой!

Дай мне знать, если я могу тебе помочь. Я думал о сложности.

Основная проблема в том, что произойдет, если есть Test с таким же именем файла. Вероятно, лучшим вариантом было бы получить относительный путь к тестовому файлу и реплицировать структуру папок в папке моментальных снимков.

@cpojer сказал мне, что @ljharb тоже заинтересовался этой функцией.

@lucasfeliciano @luispuig Есть ли в этом прогресс? Тебе не нужна помощь?

Я не пробовал ...

Просто смотрю на это сам. Честно говоря, я презираю это название каталога с двойным подчеркиванием. У Гвидо есть много ответов! Эти вещи теперь также попадают в Javascript :). Я думаю, что они выглядят беспорядочно, но конечно ... субъективно.

Я лично нахожусь в каталоге для каждого компонента лагеря и сижу свои модульные тесты как родственник коду компонента, используя соглашение component.test.js.

Я думаю, было бы неплохо иметь возможность настраивать моментальные снимки, которые также будут генерироваться как родственники компонента и тестов. В конце концов, это просто файлы ресурсов, и для моих тестов они представляют собой файлы css для компонента (которые я также сохраняю как братьев и сестер).

Кажется, здесь происходит волшебство .. https://github.com/facebook/jest/blob/master/packages/jest-snapshot/src/utils.js#L96

Мне интересно, насколько сложно будет передать это жестко запрограммированное имя каталога из конфигурации package.json (сделав текущее значение по умолчанию для обратной совместимости). Я все еще слишком новичок в JS, чтобы точно знать, как работает этот процесс.

В любом случае, открытие поддержки стиля * .test.js, но отсутствие поддержки такой же одноуровневой структуры для файлов моментальных снимков, действительно кажется несогласованным.

Привет,

Я как раз думал об этом. Я понимаю, почему основные разработчики не хотят менять эту функцию.

Если вы используете папку __testing__, сделайте все в той же папке. Но если вы работаете над разными проектами, хуже перемещать компоненты, потому что вам нужно скопировать компонент и тест в другую папку.

Но если мы используем тест с компонентом, он заполнится папками _snapshot_.

Чтобы поддерживать другую папку для снимков, нужно очень заботиться о структуре каталогов, потому что у нас может быть 2 теста / компонента с одинаковыми именами в разных папках. И снова, чтобы поделиться компонентом, снимок является частью теста.

Я получил cuestión. Возможно ли, что jest использует тот же тестовый файл для хранения снимков? Это было бы здорово и отвечало двум тенденциям.

@luispuig

Я понимаю, почему разработчики могут посоветовать в документации и FAQ, что перемещение снимков из-под компонента в структуре - плохая идея. Лично я все равно не стал бы этого делать, потому что согласился бы с ними в этом вопросе.

Тем не менее, стиль, который быстро становится нормой, заключается в размещении файлов модульных тестов как родственников тестируемого кода. Вот почему jest теперь поддерживает файлы * .test.js.

На самом деле я не понимаю, почему они не хотели бы это менять. Мы говорим об инструменте тестирования, который навязывает жестко запрограммированное мнение о структуре исходного дерева пользователя.

Предполагается, что намерение согласуется с идеей __tests__, но это совсем другое. Фактически, изолированно, если бы имя каталога снимков было навязано, то папка с точками была бы лучшим выбором, потому что она содержит «вещи, с которыми вам редко нужно возиться», очевидно, это отличается от тестов, которые являются кодом, обслуживаемым Пользователь.

Честно говоря, я новичок в мире JS (у меня 20 лет опыта в разработке JVM), и мне кажется, что «война стандартов» все еще продолжается в этой экосистеме. В любом случае, на мой взгляд, тестовая библиотека не совсем подходящее поле битвы для подобных вещей. Если бы такой инструмент, как «create-react-app», настраивал шутку самоуверенным образом, мои претензии были бы слабее, потому что такие приложения-шаблоны - разумное место для ведения войны стандартов. Люди, которые используют эти вещи, в некотором роде соглашаются с тем, чтобы в их проекте применялось чье-то мнение о структуре. Я все еще могу жаловаться, что было бы неплохо, если бы я мог отменить это (без «выброса»), но я чувствую, что случай был бы слабее.

... но библиотека тестирования, которая применяет это мнение к структуре моего репозитория git ... нет. На самом деле, не могу оторваться.

@ Уэсли холл

Я согласен. Лучше всего хранить файл моментального снимка вместе с тестовым файлом.

Меня беспокоит заполнение всей структуры папками __snapshot__. Я предлагаю поместить снимки в тестовый файл вместо создания папки снимков на уровне тестового файла. Было бы возможно?

Я тоже так считаю.

В сообщении выше я вставил ссылку на строку в коде, где __snapshots__ существует как жестко закодированная строка.

Поскольку jest можно настроить из файла package.json (https://facebook.github.io/jest/docs/configuration.html), я бы предпочел добавить новый ключ конфигурации под названием "snapshotDirectory". ", что позволяет настроить это. Лично я был бы счастлив, если бы это значение было выражено относительно теста (так что поведение, которое мы оба описываем, можно было бы настроить, указав либо «.», Либо «»), и оставив текущее значение по умолчанию.

Я мог бы попытаться составить пул-реквест по этому поводу на выходных, но я не очень хорошо знаком с механизмом, используемым для передачи этих значений конфигурации. Если вы или любой читающий знаете, как это делается, я определенно слышу об этом, иначе я разберусь.

Должен сказать, я не думаю, что их можно поместить в тестовый файл , если вы это имели в виду. В jest есть механизмы для обновления снимков и т. Д. Я бы не хотел, чтобы система изменяла какую-то часть моего js-файла модульного теста. Я бы поместил их как отдельные файлы, но как простые братья и сестры в тестовый файл js.

Может, это невозможно, но было бы здорово.

Мне действительно не нравится такое поведение. Я предпочитаю filename.test.js.snapshot

Предложение конфигурации относительного пути не будет работать, потому что каждый файл находится в разном месте в структуре. Может быть, это нормально для того, что я только что сказал. Но, честно говоря, я предпочитаю не настраивать его. Лучше иметь соглашение и подталкивать сообщество к его использованию. Это снижает утомляемость и упрощает совместное использование кода.

@luispuig

Я думаю (более или менее), что я говорю о "filename.test.js.snapshot". По сути, просто напишите те же самые файлы, которые записываются сейчас, как братьев и сестер в тестовые файлы, а не в подкаталог __snapshots__.

Думаю, я решил, что, вероятно, просто буду шутить форком и просто удалю жестко закодированную строку подкаталога в строке кода, на которую я ссылался выше, что поможет. Не будет настраиваться, но я просто буду использовать эту разветвленную версию. Будет достаточно легко перебазировать каждый будущий выпуск jest, если они не внесут изменения для поддержки этого поведения в основной ветке.

Я не думаю, что у меня будет много шансов вернуть это слияние, но если кто-то читает это и особенно заинтересован в этом небольшом форке, я, вероятно, смогу где-нибудь опубликовать его.

благодаря

@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, и получение функциональной локальной тестовой среды для моих изменений оказывается тем, что я обычно называю «головной болью».

Я знаю, что это звучит немного лениво, но если предположить, что мой анализ, приведенный выше, где-то близок к правильному, я полагаю, что тот, кто регулярно работает с этой кодовой базой и уже имеет функциональную локальную настройку разработки, вероятно, сочтет изменение относительно простым. Большая часть работы, похоже, заключается в добавлении параметра конфигурации и передаче значения через него.

Я действительно думаю, что это была бы хорошая функция, так что, возможно, я найду время и терпение, чтобы выяснить механизм конфигурации в ближайшие недели и получить PR, если никто с более глубокими знаниями кодовой базы не возьмется за это . Возможно, тебе придется потерпеть меня.

@wesleyhall Спасибо! (http://nvm.sh и nvm install node теоретически должны предоставить вам работающую среду, если вы не используете Windows)

@ljharb :) Ну, не ветеринар, но я могу

Речь идет больше о ссылках на пряжу и о том, чтобы моя локальная версия должным образом отражалась в отдельном проекте, который я могу использовать для тестирования изменений. В документации участников немного рассказывается об этом и о подключении модуля jest-cli. У меня это не сработало с первой попытки, но, вероятно, что-то глупое и очевидное.

Большая проблема, вероятно, связана с модулями jest-cli и jest-config. Параметры конфигурации упоминаются и упоминаются во многих местах. Моя IDE находит как минимум 6 различных исходных файлов, в которых есть объекты с ключом snapshotSerializers. Эти файлы не комментируются, поэтому довольно сложно сказать, для чего каждый из них и что мне нужно изменить для поддержки новой опции конфигурации. Придется немного нырнуть, но когда представится возможность, я попробую.

Не позволяйте количеству результатов пугать вас, когда вы ищете такой ключ конфигурации. Вероятно, вы получите результаты для каталогов src и build вместе с типами ключа.

Я изменил большую часть кода, чтобы добавить эту функциональность. Мне нужно проверить это, а затем написать несколько тестов. Я не буду продолжать, если вы хотите копнуть глубже и решить эту проблему самостоятельно, и я могу помочь вам указать правильное направление.

@weslyhall @wyze

Большое спасибо за вашу работу. Я очень верю, что эта важная функция закроет дискуссию на хорошем настроении.

@wyze

Нет, пожалуйста, продолжайте. Я могу посмотреть на ваш пиар и увидеть, насколько я был близок (или далек) :).

Я еще не особо разбирался в потоках, поэтому в моем опыте есть некоторые пробелы. На самом деле серьезная работа с JS началась только в январе этого года, так что да, n00b :). Хотя 20 лет на JVM. Это все просто нули и единицы в конце дня;).

Я мог бы остаться и поучиться у собравшейся толпы волшебников.

Спасибо за вашу помощь.

Нет проблем!

В последнее время я работал с Reason и начал писать тесты моментальных снимков для своих компонентов, но проблема заключалась в том, что файлы .re преобразуются в .js которые выводятся в другой каталог. Итак, мои снимки попадают в каталог, который находится в моем .gitignore потому что они созданы для тестовых файлов .js .

Это именно то, что я ищу, поэтому я могу хранить свои снимки в каталоге с моими тестами, которые написаны в .re и зарегистрированы в Git.

@wyze

Превосходно. Еще раз спасибо.

Небольшое предложение, посмотрев на PR. Одна из вещей, которую я действительно хотел сделать, - это избавиться от каталога __snapshots__ с помощью конфигурации. Конечно, все это субъективно, но мне не очень нравятся эти каталоги с двойным подчеркиванием. Хотя пиар, похоже, все еще требует этого стиля.

Если вы восстановите:

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

В конструкторе SnapshotState и, возможно, переименуйте функцию во что-то вроде getDefaultSnapshotPath, тогда я думаю, что теперь у нас будет полный контроль над каталогом моментальных снимков. Можно еще, конечно, перетащить каталог __snapshots__ в значение конфигурации, если вы хотите следовать этому соглашению, но просто разместить их в другом месте, но не будете вынуждены.

Возможно, мне стоит сделать эти комментарии по поводу самого пиара, но это просто мысль :).

@wyze

Просто понял, что я немного неправильно это понял. Атрибут пути к моментальному снимку должен быть полным путем к файлу, а не только каталогом, конечно.

Также может измениться:

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

из функции getSnapshotPath примерно так:

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

Т.е. возьмите указанный путь, если он указан, или вместо этого возьмите testPath с добавленным __snapshots__.

У меня есть структура каталогов, которая в настоящее время выглядит так:

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

Мне нравится идея @lukescott . Технически это все еще файлы JS, что-то вроде:

• 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 Вы объедините PR, реализовав предложенный вами подход?

путем добавления параметра конфигурации resolveSnapshots, который указывает на модуль с двумя функциями:

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

@cpojer, мы также можем реализовать его с помощью двух шаблонов регулярных выражений для сопоставлений 1: 1.
Прямо сейчас у нас есть в jest-resolve-dependencies

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 API. Мне нужны тесты для обеих служб, и я хочу использовать функцию моментальных снимков для хранения некоторого отфильтрованного ответа JSON, возвращаемого службой A и службой B. Допустим, я написал тесты один раз, которые могут поразить одну службу за раз (A или B). Я могу запустить их для службы A, получить снимки, затем я могу запустить их для службы B и получить новые снимки. Оказывается, служба A и служба B могут создавать разные снимки по некоторым известным причинам. Поэтому кажется разумным указать разные местоположения снимков в зависимости от того, какая служба тестируется. Поскольку я не могу сделать это через конфигурацию Jest, мне нужно поддерживать копию одного и того же теста, хранящуюся в другой папке, но я действительно хочу иметь только один тест и два разных снимка.

Надеюсь, это звучит как реальный вариант использования, чтобы получить поддержку. Я вижу, что это редкий случай, но я думаю, что это связано с другими делами, которые люди приносили сюда. Благодаря!

Похоже, в этом нет прогресса. Я хотел бы попробовать поработать над этим, так как мне эта функция очень нужна

@joshduck они не хотят видеть ↑

@cpojer Не согласен, для проектов React Native, которые могут иметь более одной платформы, действительно полезно. Проверьте рендеринг компонента на iOS, Android и на любых других устройствах. Просто способ переопределить расширение «SNAP» уже очень поможет.

Это действительно прискорбно, если вы используете установку, в которой у вас есть исходные файлы (например, TypeScript), которые проверяются, и выходные файлы (например, соответствующий JS), которые не проверяются. Файлы моментальных снимков обычно попадают в .gitignore 'd каталог.

Столько беспорядка без этой функции ...

Снимки движут моим проектом. Без этой функции я вынужден создавать собственное решение, которое избавляет от необходимости использовать Jest ... Bummer.

Мне не нравится идея размещения каталога __snapshots__ вместе с каждым тестом, и я бы предпочел иметь возможность разместить их все в одном каталоге, например, на верхнем уровне. Для меня это просто визуальная вещь, и ИМХО сотни каталогов __snapshots__ разбросанных по дереву файлов, выглядят действительно беспорядочно. К счастью, в VS Code есть простой обходной путь - просто исключите каталог __snapshots__ из проводника файлов в своих настройках следующим образом:

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

Таким образом, каталог __snapshots__ будет скрыт в проводнике файлов вашего VS-кода. Я думаю, что подобное возможно и в IDE Jetbrains.

Я потратил несколько часов, изучая это, выставил PR # 6143 на основе предыдущего предложения для всех, кто заинтересован.

Похоже, вы продвигаетесь вперед с этим @viddo. Спасибо за вашу работу, я бы очень хотел, чтобы это было объединено.

Спасибо @viddo! 😍

Он появился и будет доступен в Jest 24. В настоящее время он доступен после установки jest@beta

Если другие сочтут это полезным, вот содержание моего snapshotResolver.js реализующего предложение @assertchris :

// 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 = {
resolveSnapshotPath: (testPath, snapshotExtension) =>
testPath
.replace (/. test. ([tj] sx?) /, '.test' + snapshotExtension)
.replace ( /src([/\\]components ) /, '__snapshots__' ),

resolveTestPath: (snapshotFilePath, snapshotExtension) =>
snapshotFilePath.replace (snapshotExtension, '.js'). replace ( '__snapshots__' , 'src / components'),

testPathForConsistencyCheck: 'src / components / some.test.js',
}