Тестирование новых релизов arui-scripts

[sklyanchuk]

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

[vaagnavanesyan]

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

1. Интеграционное тестирование

Подход заключается в фактическом запуске команды и проверки её результата - вывода в консоль, созданных файлов и т.д. Этот подход может быть реализован прямо сейчас без внесения изменений в кодовую базу. Но у него есть существенные недостатки и сложности. Основным недостатком является собственно необходимость запуска команды на исполнение, что в свою очередь несет следующие неудобства:

• Нужно создать условия для изолированного запуска разных тестов, своего рода тестового фреймворка вокруг arui-scripts, который будет подготавливать тест-кейс к запуску, парсить выводы в консоль и затем подчищать созданные артефакты команды. В рамках нашего примера: необходимо добавить в проект иконку и написать тест, который запустит сборку и проверит размер обработанного файла.
• Тест-кейсы получатся громоздкими, и, вероятно медленными. Представим, что мы написали 5 тест-кейсов на сжатие разных иконок. Чтобы прогнать тесты придется 5 раз запускать сборку, проверять результат, а при необходимости еще и наводить порядок на диске между тестами
• Отсутствие возможности что-либо замокать. Мы просто запускаем процесс, способа вмешаться в то, что он делает у нас нет, а соответственно будет сложно имитировать сценарии, завязанные на сеть или прочую инфру

2. Юнит-тестирование

Более строгий, изолированный и масштабируемый подход. Из недостатков - необходимость переработать кодовую базу. Суть подхода в том, чтобы ввести абстракцию над командами. Через абстракцию команда может быть вызвана программно, а не только путем реального запуска приложения. Это дает пространство для маневра: можно замокать сеть или файловую систему, а также проверять код/текст возникшей ошибки без необходимости парсить консоль.
В нашем примере с иконками, мы могли бы замокать fs, запустить команду обычным вызовом функции, и проверить её результат

Пример ручной реализации подхода:
Команда: https://github.com/microsoft/appcenter-cli/blob/master/src/commands/crashes/upload-symbols.ts
Тест: https://github.com/microsoft/appcenter-cli/blob/master/test/commands/crashes/upload-symbols/upload-symbols-test.ts

Также можно взять довольно распространенный фреймворк для написание CLI (https://www.npmjs.com/package/commander), на котором можно реализовывать тестируемые приложения:
https://circleci.com/blog/testing-command-line-applications/
https://fireflysemantics.medium.com/unit-testing-commander-scripts-with-jest-bc32465709d6
https://javascript.plainenglish.io/how-to-test-a-node-js-command-line-tool-2735ea7dc041
https://www.youtube.com/watch?v=ngbL6x4ma3Y

[sanityFair]

А что если для начало определить критерии тестирования нового билда? Так будет проще понять, что потребуется для тестирования

[vaagnavanesyan]

Попробовать написать свой плагин, предоставляющий статистику по результатам сборки
https://webpack.js.org/api/compiler-hooks/