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

--- Пропустите, если хотите сразу перейти к обсуждению ---

Мое отсутствие было в некотором смысле побочным продуктом отраслевой культуры. Фронтенд-тестирование всегда было чем-то важным, но еще десять лет назад структура компании отделяла задачи тестирования от процесса разработки. Итак, у нас была специальная команда контроля качества, которая писала E2E/автоматические тесты для нас, разработчиков. Так что тестирования даже не было в описании вакансии. Кроме того, печальная правда небольших стартапов заключается в том, что доставка всегда превыше всего остального, поэтому, поскольку тестирование снижает производительность, мы, разработчики, не тестировали. У нас даже не было установленной в репозитории тестовой библиотеки (Jasmine/Mocha/PhantomJS...).

Я получил вторую работу в гораздо более крупной компании (в команде потребительской платформы было около 150 разработчиков?). Однако, по сути, тестирования не было. У каждой команды (команды, разделенные по таким функциям, как оформление заказа, лояльность, регистрация...) снова были выделенные члены отдела контроля качества, которые писали эти E2E-тесты. Как только эта культура появилась и контроль качества был исключен из бюджета, никто не стал их брать, потому что не у кого было этому научиться. Я пытался провести E2E-тестирование для нашей команды, но оставшийся код даже не был работоспособным и полон очевидных ошибок (много WTF). В сочетании с сжатыми сроками СНОВА тестирование отставало. Единственный раз, когда люди говорили о тестировании, это были служебные функции и специальные хуки реагирования.

--- обсуждение начинается ---

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

Не стесняйтесь присоединяться к обсуждению. Это затронуло как минимум 300 моих бывших коллег!

1.) проверить глобальные состояния:
По моему опыту, одна из самых неприятных особенностей — это поведение типа «если это произойдет, мы сделаем это за вас автоматически». Например, одно из моих приложений представляло собой панель визуализации графиков, которую можно было легко настроить. Одно изменение конфигурации может привести к изменению и других конфигураций, в зависимости от возвращаемых данных или нет. Некоторые побочные эффекты конфигурации не являются очевидными. Итак, вам нужно протестировать автоматические изменения конфигурации и проверить, сохраняется ли состояние/неизменяется/последовательно по всем направлениям. Поэтому, если вы проводите тестирование такого типа поведения, согласованное с проектом проекта, менеджерами, дизайнерами и командой контроля качества, это очень ценно.

2.) не тратьте много времени на проверку целостности ввода пользовательского интерфейса:
Я вижу довольно много руководств, посвященных тестированию входных данных, например, когда я набираю «Тейлор Свифт» в строке поиска и нажимаю Enter, наша функция поиска получает Тейлор Свифт в качестве входных данных.

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

если вам платят за строки кода, продолжайте :)

3.) желательно проверить входные данные как побочный эффект входных данных:
В отличие от пункта 2, вы захотите протестировать функциональные вызовы, которые являются полностью побочными эффектами взаимодействия с пользователем. Например, когда пользователь нажимает на кнопку, должен быть вызван запрос на регистрацию этого действия пользователя для анализа данных. Этот тип побочных эффектов, которые полностью отделены от основной функциональности, должен автоматически тестироваться, чтобы нас не застали врасплох некоторые непреднамеренные изменения. Непрофильный побочный эффект может быть важен для других команд, я был в одной из таких команд :D

Так как же составить требования к тестированию?
давайте разберем архитектуру интерфейса: MVC (вы можете сказать, что вы MVVM или нет, это не имеет особого значения).

V - представление (html/jsx): Это отлично подходит для тестирования браузеров E2E/без заголовков и является отраслевым стандартом.

C — контроллер (бизнес-логика): потратьте некоторое время на проверку правильности функций. Например, если у вас есть/абстрагируются чистые функции, сохраняется ли ожидаемый процесс ввода-вывода? В некоторой степени отраслевой стандарт, но люди обычно не утруждают себя преобразованием функций с состоянием в чистые функции и тестирование.

M — модель (вызовы/состояния API): это то, на чем я хочу сосредоточиться больше всего. ваши состояния (без рендеринга) должны быть глобальными и одноэлементными для каждой концепции. Идея не новая, поскольку по сути это Redux. Однако для наших целей тестирования это не обязательно должен быть Flux. У вас могут быть атомы джотай, но вы можете написать оболочку, чтобы вы могли предоставить свои централизованные функции установки для тестирования.

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

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