После более чем 5 лет работы в области разработки интерфейса, около 95% из которых были в стартапах, я хотел бы поделиться некоторыми своими мыслями о тестировании интерфейса. Тестирование, как мы знаем, имеет много преимуществ для кодовой базы и ее продукта. Однако это также требует времени и усилий, которые могут быть в большом почете в стартовой среде.
В стартапах могут пострадать такие вещи, как тестирование, документирование и разработка стандартных процессов, поскольку компания больше ориентируется на результат. Часто компания озабочена такими вещами, как как можно скорее получить доказательство концепции, капитулировать перед требованиями нового/потенциального клиента и войти в дверь до того, как закончатся деньги.
Таким образом, люди в такой ситуации могут задаться вопросом: «Должен ли я внедрять тестирование? Если да, то какой? И сколько?". Это мой опыт, хотя, конечно, помните, что все компании разные, поэтому не забывайте учитывать контекст при принятии решения. Эти принципы могут применяться и к более крупным компаниям, хотя мой опыт работы с ними довольно ограничен.
Во фронтенд-фреймворках «модульное тестирование» обычно относится к тестированию отдельных компонентов. И их рендеринг, и их внутренний функционал. Это дает преимущества, в том числе:
- Обеспечение того, чтобы компонент отображал правильные элементы
- Проверка стиля компонента
- Проверяем, что изменения в state/props/etc. вызывают правильные изменения в рендеринге компонента
Это детальный подход, при котором каждая часть приложения проверяется изолированно, чтобы убедиться, что оно работает должным образом.
Сквозное (E2E) тестирование — это более широкий подход, проверяющий выполнение потоков приложения от начала до конца. При разработке внешнего интерфейса это означает тестирование с точки зрения пользователя с использованием таких инструментов, как Cypress или puppeteer. Они имитируют среду браузера и автоматизируют взаимодействие, проверяя такие вещи, как «если я наберу это здесь и нажму эту кнопку, появится ли этот элемент на странице». Потоки могут включать в себя такие вещи, как вызовы API или обработка данных, все из которых не тестируются специально, а косвенно проверяются путем проверки потока, частью которого они являются.
Итак, вопрос в том, какое тестирование следует использовать?
Что ж, очевидно, лучшим ответом было бы использовать и то и другое, тестируя каждый отдельный компонент и каждый отдельный поток E2E. Но, как я уже упоминал, в стартапах это может быть неосуществимо. Лично я предпочитаю E2E-тестирование, и объясню почему.
Наибольшая польза от модульного тестирования приходит, когда вы правильно выделяете время и проектируете компоненты. Делая их чистыми и модульными, логически разбивая их, гарантируя, что они являются универсальными и пригодными для повторного использования, оптимизируя состояние/реквизиты, чтобы они были только тем, что необходимо, и не более или менее, и т. д. Таким образом, тесты просты и их легко писать, существующие компоненты не будут нуждаться в обновлении своих тестов так часто (поскольку компоненты можно использовать повторно и с меньшей вероятностью потребуют рефакторинга), а основное время, затрачиваемое на тестирование, будет просто на написание тестов для новых компонентов.
Однако в стартапах, где рабочая сила может быть ограничена, сроки могут быть жесткими, требования могут часто меняться, а текучесть разработчиков может быть высокой, проектирование высококачественных компонентов обычно отодвигается от списка приоритетов в пользу удовлетворения функциональных требований. Таким образом, компоненты и их иерархия могут быть запутанными. Это может сделать модульное тестирование намного более трудоемким и привести к тому, что много времени будет потрачено на тесты рефакторинга при обновлении/рефакторинге ваших компонентов.
И наоборот, при E2E-тестировании, да, при изменении потока вам придется обновлять свои E2E-тесты, но часто это происходит намного быстрее. Если, например, вы изменяете элемент, на который вы нажимаете на определенном этапе потока, изменение этого в тестах E2E может быть изменением одной строки кода, но написание модульных тестов для этого нового элемента (который может быть выполнен из нескольких компонентов) может занять гораздо больше времени.
Другая причина заключается в том, что разработка внешнего интерфейса очень гибкая, и существует огромное количество способов сделать большинство вещей. От количества доступных интерфейсных библиотек пользовательского интерфейса до вспомогательных библиотек, которые вы можете использовать для таких вещей, как стилизация, вплоть до того, как вы проектируете свои компоненты и их иерархию.
В стартапах более вероятны технические изменения, такие как изменения библиотек или фреймворков, поскольку у них, вероятно, будет больше свободы пробовать новые вещи, чтобы увидеть, что будет работать в долгосрочной перспективе. Это может означать переписывание тестов для работы с новой технологией и может занять дополнительное время.
Однако с E2E-тестированием вы можете изменить все приложение с Vue на React и никогда не касаться ни одного теста, поскольку тесты не зависят от технологии, лежащей в основе приложения. Это может быть полезно, потому что, опять же, в стартапах все происходит очень быстро, и если вы вносите большие изменения в технологию, вы хотите сэкономить как можно больше времени.
Мое последнее замечание больше зависит от личных предпочтений, но я считаю, что тесты E2E проще писать в целом и они более доступны. В модульном тестировании есть такие вещи, как имитация, заглушка, имитация localStorage и многое другое. И наоборот, в тестах E2E они больше похожи на действия из реальной жизни, такие как «введите это», «щелкните это», «перейдите сюда», «проверьте правильность URL-адреса». Это может облегчить вход при реализации тестирования.
Как ни странно, когда я гуглил на эту тему, я часто находил статьи типа эта, в которых говорилось, что E2E реализуется медленнее всего, а модульное тестирование — быстрее всего. Мой практический опыт работы со стартапами определенно свидетельствует об обратном. Может, те статьи не вписываются в контекст, может, мой подход к тестированию имеет какие-то принципиальные недостатки, сложно сказать, статьи достаточно высокого уровня.
Конечно, у модульного тестирования есть свои преимущества, а у E2E есть свои недостатки, например. при E2E-тестировании, если тест терпит неудачу, может быть сложнее отследить, что именно пошло не так (поскольку функциональность абстрагируется). Один метод объективно не превосходит другой. Я только что обнаружил, что в моей работе в стартапах E2E-тестирование дает наибольшую отдачу от времени, когда речь идет о написании и поддержке тестов в среде, где время и усилия в большом почете.
Повторюсь, каждый бизнес уникален, и вы можете обнаружить, что ваш конкретный стартап берет набор компонентов и постоянно перестраивает то, как они сочетаются друг с другом, и потоки, которые они создают, и в этом случае подход, ориентированный на модульное тестирование, может быть лучше. Главный вывод, который я хочу подчеркнуть, заключается в том, что вы не должны без разбора применять общие правила к средам, которые могут варьироваться миллионом тонких способов.
Поскольку, несмотря на то, что прошло более 5 лет, я работал только в нескольких компаниях и работал над несколькими продуктами, мне было бы интересно узнать об опыте других людей в области тестирования интерфейса в стартапах.
