Skip to content

Latest commit

 

History

History
42 lines (39 loc) · 6.01 KB

basic-workflow.md

File metadata and controls

42 lines (39 loc) · 6.01 KB
Raw

Базовый рабочий процесс

Внесение изменений в библиотеку обычно идет по одному и тому же сценарию, который в том числе проверяется в пулл-реквестах. По мере возможности мы практикуем test-driven development, без тестов новые фичи не принимаются.

  1. Склонируйте себе репозиторий (если вы еще этого не сделали)
  2. Определите, какие именно изменения в генерируемом коде вы ожидаете и напишите тест. Убедитесь, что написанный тест не проходит. Если вы пишете эталонный тест, убедитесь, что он добавлен в нужную категорию.
  3. Внесите изменения в код библиотеки.
  4. Запустите тест и убедитесь, что он проходит.
  5. Если обновились эталоны тестов, то выполните yarn run _update_test_specimens.
  6. Запустите yarn sniff для проверки кода линтером и запуска всех остальных тестов. Почините то, что не проходит.
  7. git commit, git push, создайте пулл-реквест на github, вы великолепны.

Особенности юнит-тестирования

  1. Тесты лежат в src/__tests__ и выполняются при помощи jest.
  2. Тесты разделены по категориям для ускорения их прогона, при этом каждый тестовый файл представляет отдельную категорию. Некоторые тесты используют эталоны (specimens) для сравнения ожидаемого и фактического результата транспиляции. В случае несовпадения, тест проваливается, а рядом с эталонным файлом записывается одноименный файл с постфиксом '.result' для удобства сравнения. Тесты разделены по категориям:
    1. astTools: тесты, связанные со вспомогательными функциями обхода AST
    2. byType: эталонные тесты отдельных синтаксических конструкций
    3. usageGraph: тесты, связанные с графом использования переменных (функциональность unused code elimination)
    4. stdlibMethods: эталонные тесты отдельных функций стандартной библиотеки
    5. components: эталонные тесты обработки react-компонентов
    6. ssr: комплексный тест, использующий демо-проект для сравнения результатов серверного рендеринга в оригинальном React и после транспиляции с помощью elephize.
    7. watcher: тесты, связанные с watch-режимом. Также используют отдельные эталоны (watchSpecimens) для сравнения ожидаемого и фактического результата. В эталонах watcher-тестов используются diff-файлы для применения изменений к исходным файлам и сравнения вывода после применения изменений.
  3. Нужно заметить, что независимость тестов в одной и той же категории в общем случае не обеспечивается автоматически. В частности, набор эталонов загружается в компилятор typescript параллельно (это сделано с целью ускорения прогонов). Из-за этого в эталонах необходимо вручную обеспечивать уникальность именования переменных в глобальной области, в ином случае при компиляции typescript будет выдавать ошибки несовпадения типов.
  4. Для отладки тестов можно использовать любые средства отладки jest, запуская его с фильтром по категории, например: yarn test -t ts2php.components. Чтобы отладить конкретный тест внутри категории, проще всего закомментировать те тесты, которые на данный момент не нужны. Будьте внимательны, чтобы не закоммитить в репозиторий тестовые категории с закомментированными тестами.
  5. В некоторых эталонных тестах допустимо указывать коды ошибок, которые ожидаемы в данном конкретном тесте (expectedErrors), либо ошибки, наличие которых должно провалить тест (failOnErrors). Коды ошибок нужно брать из вывода компиляции elephize. Сами коды генерируются автоматически из сообщений об ошибках (до подстановки значений в плейсхолдеры), поэтому в случае изменения сообщений об ошибке потребуется также актуализировать в тестах их коды.