Я провел ночь после выступления Майка Брокки на NgAtlanta 2018, работая над тем, как использовать настраиваемые схемы для расширения или замены файлов, выводимых Angular CLI.
В своем выступлении он сослался на недавнюю публикацию одного из авторов схемы о том, как создавать собственные схемы, которые послужили моей отправной точкой. (Если вы не знакомы со схемами, я настоятельно рекомендую посмотреть доклад - соответствующая часть начинается в 5:07 - и прочитать сообщение, прежде чем вернуться сюда, чтобы поговорить о тестировании.)
Одной из инструкций, которую я не смог понять той ночью (и с которой до сих пор борюсь), был фрагмент кода для отладки вашей схемы с помощью Chrome:
node --inspect-brk $(which schematics) .:myComponent --name=test
Через несколько месяцев после конференции я написал свою первую схему на корпоративной неделе хакерских атак, чтобы добавить стиль по умолчанию и поведение аутентификации в новые приложения. Мы написали несколько элементарных модульных тестов, которые подтверждали, что файлы появляются в ожидаемом месте файлового дерева, но в значительной степени полагались на инструкции console.log для отладки проблем приложений.
Когда пришло время убедиться, что у нас есть полнофункциональное приложение, у нас не было другого выбора, кроме как запустить следующий набор команд:
npm run build ng new demo-schematic --skipInstall=true # open VS code to see if the output code passes the eyeball test npm install ng serve
Подходит для первой итерации, но не для цикла разработки, который я бы одобрил для кого-либо в долгосрочной перспективе, тем более что проблема, наиболее часто обнаруживаемая в install/serve цикле, была опечатками: 😤.
В этом посте я расскажу о настройке VS Code для отладки модульных тестов для схем Angular; отладка схем вне контекста модульного теста; и мысленный эксперимент о том, как мы могли бы улучшить жизненный цикл разработки, о котором я упоминал выше.
Настройка VS Code для отладки
Не стесняйтесь пропустить этот раздел, если вы уже знакомы со структурой и назначением launch.json и task.json. Если вы этого не сделаете, мы быстро рассмотрим некоторые основные концепции, прежде чем вернуться к конкретным темам Angular. В этом разделе представим, что вы готовитесь к предстоящему собеседованию, поэтому у вас есть папка с кодом практики. Ваш launch.json содержит конфигурации отладки, которые позволят вам пройти через ваше решение. Ниже приведен образец объекта конфигурации для отладки вашего fizzbuzz.js кода:
Вы можете запустить отладчик либо с помощью значка ошибки на левой панели активности, либо из раскрывающегося списка отладки в верхней строке меню (горячая клавиша F5 также поможет) - просто убедитесь, что выбрали правильную конфигурацию, если у вас есть больше чем один.
Если launch.json имеет наши конфигурации отладки, какова может быть роль task.json? Документация VS Code предлагает это резюме:
[Инструменты] для автоматизации таких задач, как линтинг, сборка, упаковка, тестирование или развертывание программных систем ... в основном запускаются из командной строки и автоматизируют работу внутри или вне внутреннего цикла разработки программного обеспечения ... Учитывая их важность в жизненном цикле разработки, это очень полезно иметь возможность запускать инструменты и анализировать их результаты из VS Code.
Подобно структуре launch.json, этот файл содержит набор потенциальных задач, которые мы можем вызвать. Если в вашем рабочем пространстве еще нет файла конфигурации задачи, вы можете создать его с помощью Терминал ›Настроить задачи в верхней строке меню. Наша примерная задача запускает простую команду оболочки:
В следующем разделе мы настроим более подходящую задачу сборки для наших схем Angular, чтобы всегда отлаживать самую последнюю версию кода схемы.
Отладка схем с помощью тестов
С этого момента схема, которую мы собираемся отлаживать, представляет собой слегка измененную версию схемы текста лицензии, продемонстрированной в публикации Schematics: An Introduction, о которой я поделился ранее. Если вы хотите начать с моей версии, которая удаляет вызов внешней схемы, вы можете проверить ее в моем репозитории GitHub. Давайте соединим вместе файлы launch.json и task.json, чтобы увидеть, как мы можем начать отладку этой схемы.
Здесь объекты конфигурации задачи вызывают сценарий сборки для компиляции нашего TypeScript до целевой версии JavaScript (этот сценарий сборки указывается в корне проекта в файле package.json).
Есть несколько важных различий между приведенной ниже конфигурацией отладки и нашим псевдообъектом для отладки fizzbuzz.js.
Следует выделить несколько ключевых отличий. Во-первых, вместо явной ссылки на имя файла, который мы хотим отладить, мы передаем отфильтрованный набор файлов в jasmine.js (не забудьте установить точку останова в тесте или тестах, которые вы хотите отлаживать). Во-вторых, мы предоставляем соответствующее имя задачи препроцессора из нашего task.json. Задача сборки может добавить некоторые минимальные накладные расходы, поэтому, если вы предпочитаете делать это вручную, когда это необходимо, убедитесь, что вы не закончили как этот повар.
Полный тест, который мы хотим запустить, выглядит примерно так:
И это чувство удовлетворения от правильной настройки приложения, чтобы вы могли отлаживать и запускать свой первый модульный тест?
¿Que Maravilloso, не так ли?
Отладка схем без тестов
Теперь, когда вы выполнили свой первый модульный тест, давайте посмотрим, как напрямую отлаживать код приложения. Задача предварительной обработки npm run build не изменилась, но мы вызовем ее из дополнительной конфигурации отладки (не забудьте запустить npm i @angular-devkit/schematics-cli из командной строки, прежде чем запускать эту конфигурацию отладки в первый раз).
Сейчас мы вызываем другую программу, schematics.js вместо jasmine.js, и предоставляем ей несколько другие программные аргументы. В этом массиве args мы предоставляем два аргумента: элемент коллекции схем, который мы хотим запустить, и путь к исходному каталогу для поиска отсутствующих текстов лицензий (функционально аргументы, которые мы передаем, эквивалентны запуску ng add-license --sourceDir=src --dryRun=true через интерфейс командной строки Angular).
Снова установите точку останова в соответствующем index.ts файле схемы и запустите отладчик. Помните ту несколько загадочную команду отладки из начала руководства? Он все еще выполняется, но теперь наш launch.json организует для нас все аргументы пути и ссылки на файлы (и в качестве дополнительного бонуса мы можем оставаться в VS Code для отладки, а не переходить в Chrome).
К сожалению, поскольку мы начинаем с пустого файлового дерева, здесь не так много схематического кода, в который можно было бы перейти. Однако это может быть не ваш опыт работы со схемами новых приложений, схемами, которые имеют дело со статическими файловыми ресурсами или строковыми шаблонами - если это не так, я хотел бы услышать от вас, когда вы сочтете этот процесс отладки полезным.
Написание тестов более высокого качества
В этом разделе я хочу провести прошлые тесты, которые делают простые утверждения о файлах, появляющихся в ожидаемом месте в дереве файлов, или о том, что конкретный файл содержит ожидаемую текстовую строку, чтобы рассмотреть другие альтернативы. Что может означать написание более строгого набора тестов для наших схем?
Идея этого эксперимента исходит из тестовых примеров для Prettier (если вы не знакомы с Prettier, это отличный инструмент для форматирования кода, который вы можете подключить либо к своей среде IDE, либо как часть цикла коммит-сборка). И ваша настраиваемая схема, и Prettier выполняют код для генерации и форматирования исходного кода, который по-прежнему должен быть действительным во время компиляции или выполнения в целевом приложении.
Разработчики, участвующие в Prettier, решили эту проблему с помощью тестов моментальных снимков Jest, которые сравнивают серию выходных данных отформатированного кода с каноническим ожиданием. Я не был знаком с тестированием Jest и имел минимальный интерес к интеграции новой библиотеки тестирования в мое решение Angular, поэтому вместо этого я решил написать свой собственный сопоставитель для Jasmine. Я предполагал, что результат будет примерно таким:
Моя черновая версия пользовательского сопоставителя также доступна как часть репозитория для этой демонстрации. Вот краткий, но не исчерпывающий список некоторых грубых моментов в этом черновике:
- Хрупкость теста
- Ведение пользовательского кода сопоставления независимо от кода приложения
- Предоставление значимых сообщений об ошибках о символах, в которых содержимое файла начинает расходиться
- Синхронное и асинхронное взаимодействие с файловой системой и библиотекой модульного тестирования
Как видите, эта работа все еще продолжается, и я все еще пытаюсь понять, добавляет ли дополнительная сложность (даже если это всего лишь несколько строк кода) ценность и надежность нашему жизненному циклу разработки или просто сложность. Если вы проводили этот тип тестирования схем и отказались от этой идеи (или сочли это действительно ценным процессом тестирования), я хотел бы услышать ваше мнение в комментариях.
Заворачивать
Вот и все! К этому моменту вы должны иметь возможность настроить VS-код для отладки схемы напрямую и с помощью модульных тестов. Для наших демонстрационных целей мы написали несколько простых тестов на довольно простой схеме. Если у вас есть более сложные схемы для тестирования или другие вопросы по другим темам тестирования схем, например, более глубокое погружение в настройку фиктивной файловой системы для тестирования, не стесняйтесь написать мне.
