Тестирование на Frontend: что и как тестировать, и какой инструмент использовать?

Question

Я писал тесты для своего кода Ruby некоторое время, но, как разработчик frontend, я, очевидно, заинтересован в том, чтобы привести это в код, который я пишу для своего кода frontend. Существует довольно много различных вариантов, которые я играл с:

• CasperJS
• Capybara & Rspec
• Jasmine
• огурца или просто Rspec

Что люди, использующие для тестирования? И что дальше, что люди проверяют? Просто JavaScript? Ссылки? Формы? Жесткий код?

Любые мысли были бы весьма благодарны.

Answer 1

Для этого есть много вариантов и инструментов. Но их выбор зависит от того, есть ли у вас веб-интерфейс или это настольное приложение?

Предположим из инструментов, о которых вы упоминали, это веб-интерфейс. Я бы предложил Selenium (aka WebDriver): http://seleniumhq.org/docs/

Существует множество языков, которые он поддерживает (Ruby находится в списке). Его можно запускать во множестве браузеров, это довольно легко использовать с большим количеством учебных пособий и советов. О, и это бесплатно, конечно :)

Answer 2

У меня были те же вопросы несколько месяцев назад, и, поговорив со многими разработчиками и проведя много исследований, я узнал об этом. Вы должны выполнить модульный тест на свой JavaScript, написать небольшой набор тестов интеграции пользовательского интерфейса и избежать инструментов тестирования записи и воспроизведения. Позвольте мне объяснить это более подробно.

Во-первых, рассмотрите test pyramid. Это интересная аналогия, созданная Майком Кон, которая поможет вам решить, какой тип тестирования вы должны делать. В нижней части пирамиды находятся единичные тесты, которые являются прочными и обеспечивают быструю обратную связь. Они должны стать основой вашей стратегии тестирования и, таким образом, занимать большую часть пирамиды. Наверху у вас есть тесты пользовательского интерфейса. Это те тесты, которые напрямую взаимодействуют с вашим пользовательским интерфейсом, например, например, Selenium. Хотя эти тесты могут помочь вам найти ошибки, они дороже и обеспечивают очень медленную обратную связь. Кроме того, в зависимости от используемого вами инструмента они становятся очень хрупкими, и вы в конечном итоге тратите больше времени на поддержание этих тестов, чем на запись фактического кода производства. Уровень обслуживания, в середине, включает интеграционные тесты, для которых не требуется интерфейс. Например, в Rails вы проверите свой интерфейс REST напрямую, а не взаимодействуете с элементами DOM.

Теперь вернемся к вашему вопросу. Я узнал, что могу значительно уменьшить количество ошибок в моем проекте, которое представляет собой веб-приложение, написанное в Spring Roo (Java) с кучей JavaScript, просто написав достаточно блок-тестов для JS. В моем приложении много логики написано в JS, и это то, что я тестирую здесь. Меня не волнует, как на самом деле будет выглядеть страница, или если анимация играет так, как должна. Я проверяю, будут ли модули, которые я пишу в JS, будут выполнять ожидаемую логику, если классы элементов правильно назначены и если условия ошибки хорошо обработаны. Для этих тестов я использовал Жасмин. Это отличный инструмент. Это очень легко учиться и имеет приятные издевательства, которые называются шпионами. Jasmine-jQuery добавляет большую функциональность, если вы используете jQuery. В частности, он позволяет вам указывать приборы, которые являются фрагментами кода HTML, поэтому вам не нужно вручную издеваться над DOM. Я интегрировал этот инструмент с maven, и эти тесты являются частью моей стратегии CI.

Вы должны быть осторожны с тестами UI, особенно если вы полагаетесь на инструменты записи/воспроизведения, такие как Selenium. Поскольку пользовательский интерфейс часто меняется, эти тесты продолжают ломаться, и вы потратите много времени на выяснение, действительно ли тесты потерпели неудачу или они просто устарели. Кроме того, они не добавляют столько же значения, сколько и модульные тесты. Поскольку им нужна интегрированная среда для запуска, вам в основном нравится запускать их только после того, как вы закончите разработку, когда стоимость исправления будет выше.

Для тестов дыма/регрессии, однако, тесты на интерфейс очень полезны. Если вам нужно их автоматизировать, вы должны следить за некоторыми опасностями. Напишите ваши тесты, не записывайте их. Записанные тесты обычно полагаются на автоматически генерируемые xpaths, которые ломаются для каждого небольшого изменения, которое вы делаете в своем коде. Я считаю, что Cucumber является хорошей основой для написания этих тестов, и вы можете использовать его вместе с WebDriver для автоматизации взаимодействия с браузером. Код мышления об испытаниях. В тестах UI вам нужно будет легко найти элементы, чтобы вам не приходилось полагаться на сложные xpaths. Добавление элементов класса и идентификатора, где вы обычно не будете частыми. Не записывайте тесты для каждого маленького уголка. Эти тесты дороже писать и слишком долго работать. Вы должны сосредоточиться на случаях, которые исследуют большинство ваших функций. Если вы пишете слишком много тестов на этом уровне, вы, вероятно, испытаете те же функции, которые вы ранее тестировали на своих модульных тестах (предположив, что вы их написали).

В моем текущем проекте я использую Spock и Geb для написания тестов пользовательского интерфейса. Я нахожу эти инструменты изумительными. Они написаны в Groovy, что лучше соответствует моему Java-проекту.

Answer 3

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

Так что в плане тестирования FE я потратил много времени, используя karma с Jasmine, хотя карма будет работать хорошо с другими наборами тестов, как мокко & QUnit. Хотя они великолепны, и карма позволяет вам напрямую взаимодействовать с браузерами для запуска ваших тестов. Недостатком является то, что ваш тестовый набор становится большим, и он может стать довольно медленным.

В последнее время я переехал в Jest, который намного быстрее, и если ваше приложение для написания приложения использует enzyme с проверкой оснастки, вы получите действительно хорошее покрытие. Говоря о покрытии, Jest имеет стамбульское покрытие, встроенное и настроенное и издевательское, действительно прост в использовании. Недостаток его не проверяется в браузере, и он использует что-то под названием jsdom, которое быстро, но имеет несколько неприятностей. Лично я не считаю это большой проблемой, особенно когда компилирую свой код через webpack/babel, что означает, что ошибки в кросс-браузере довольно незначительны и находятся далеко друг от друга, поэтому обычно это не проблема, если вы вручную проверите тест (и imo вы должны).

С точки зрения работы в стеке рельсов, это очень легко теперь, когда драгоценный камень webpacker теперь доступен, а использование npm и узла, как правило, намного более исключено. Я бы рекомендовал использовать nvm для управления версиями вашего узла

Хотя это не строгое тестирование, я бы также рекомендовал использовать перемычку, так как это также вызывает много проблем в вашем коде. Для JS я использую eslint с prettier и SCSS/CSS Я использую stylelint

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

В любом случае, я надеюсь, что это поможет людям, которые рассматривают вопрос.