Я писал тесты для своего Ruby-кода некоторое время, но, как разработчик frontend, мне явно интересно привести это в код, который я пишу для моего кода frontend. Существует довольно много разных вариантов, с которыми я играл:
Что люди используют для тестирования? И что дальше, что люди проверяют? Просто JavaScript? Ссылки? Формы? Hardcoded content?
Любые мысли будут очень благодарны.
У меня были те же вопросы несколько месяцев назад, и, поговорив со многими разработчиками и проведя много исследований, я узнал об этом. Вы должны unit test использовать свой JavaScript, написать небольшой набор тестов интеграции пользовательского интерфейса и избегать инструментов тестирования и воспроизведения. Позвольте мне объяснить это более подробно.
Сначала рассмотрим тестовую пирамиду. Это интересная аналогия, созданная Майком Кон, которая поможет вам решить, какой тип тестирования вы должны делать. В нижней части пирамиды находятся единичные тесты, которые являются прочными и обеспечивают быструю обратную связь. Они должны стать основой вашей стратегии тестирования и, таким образом, занимать большую часть пирамиды. Наверху у вас есть тесты пользовательского интерфейса. Это те тесты, которые напрямую взаимодействуют с вашим пользовательским интерфейсом, например, например, Selenium. Хотя эти тесты могут помочь вам найти ошибки, они дороже и обеспечивают очень медленную обратную связь. Кроме того, в зависимости от используемого вами инструмента они становятся очень хрупкими, и вы в конечном итоге тратите больше времени на поддержание этих тестов, чем на запись фактического кода производства. Уровень обслуживания, в середине, включает интеграционные тесты, для которых не требуется интерфейс. Например, в Rails вы проверите свой интерфейс REST напрямую, а не взаимодействуете с элементами DOM.
Теперь вернемся к вашему вопросу. Я узнал, что могу значительно уменьшить количество ошибок в моем проекте, которое представляет собой веб-приложение, написанное в Spring Roo (Java) с кучей JavaScript, просто написав достаточно модульных тестов для JS. В моем приложении много логики написано в JS, и это то, что я тестирую здесь. Меня не волнует, как на самом деле будет выглядеть страница, или если анимация играет так, как должна. Я проверяю, будут ли модули, которые я пишу в JS, будут выполнять ожидаемую логику, если классы элементов правильно назначены и если условия ошибки хорошо обработаны. Для этих тестов я использовал Жасмин. Это отличный инструмент. Это очень легко учиться и имеет приятные издевательства, которые называются шпионами. Jasmine-jQuery добавляет большую функциональность, если вы используете jQuery. В частности, он позволяет вам указывать приборы, которые являются фрагментами кода HTML, поэтому вам не нужно вручную издеваться над DOM. Я интегрировал этот инструмент с maven, и эти тесты являются частью моей стратегии CI.
Вы должны быть осторожны с UI-тестами, особенно если вы полагаетесь на инструменты записи/воспроизведения, такие как Selenium. Поскольку пользовательский интерфейс часто меняется, эти тесты продолжают ломаться, и вы потратите много времени на выяснение, действительно ли тесты потерпели неудачу или они просто устарели. Кроме того, они не добавляют столько же значения, сколько и модульные тесты. Поскольку им нужна интегрированная среда для запуска, вам в основном нравится запускать их только после того, как вы закончите разработку, когда стоимость исправления будет выше.
Однако для тестов на дым/регрессию тесты UI очень полезны. Если вам нужно их автоматизировать, вы должны следить за некоторыми опасностями. Напишите свои тесты, не записывайте их. Записанные тесты обычно полагаются на автоматически генерируемые xpaths, которые ломаются для каждого небольшого изменения, которое вы делаете в своем коде. Я считаю, что Cucumber является хорошей основой для написания этих тестов, и вы можете использовать его вместе с WebDriver для автоматизации взаимодействия с браузером. Кодовое мышление о тестах. В тестах UI вам нужно будет легко найти элементы, чтобы вам не приходилось полагаться на сложные xpaths. Добавление элементов класса и идентификатора, где вы обычно не будете частыми. Не записывайте тесты для каждого маленького углового футляра. Эти тесты дорогие для записи и слишком длинные для запуска. Вы должны сосредоточиться на случаях, которые исследуют большинство ваших функций. Если вы написали слишком много тестов на этом уровне, вы, вероятно, испытаете те же функции, которые вы ранее тестировали на своих модульных тестах (предположив, что вы их написали).
В моем текущем проекте я использую Spock и Geb для написания тестов пользовательского интерфейса. Я нахожу эти инструменты изумительными. Они написаны в Groovy, что лучше соответствует моему Java-проекту.
Есть много вариантов и инструментов для этого. Но их выбор зависит от того, есть ли у вас веб-интерфейс или это настольное приложение?
Предположим из инструментов, о которых вы упоминали веб-интерфейс. Я бы предложил Selenium (aka WebDriver): http://seleniumhq.org/docs/
Существует множество языков, которые он поддерживает (Ruby находится в списке). Его можно запускать во множестве браузеров, а его довольно легко использовать с большим количеством обучающих программ и советов. О, и это бесплатно, конечно:)
Я, хотя, поскольку этот пост получает много симпатий, я бы опубликовал свой ответ на мой вопрос, так как сейчас я пишу много тестов и как вы тестируете переднюю часть, теперь много изменилось.
Итак, с точки зрения тестирования FE я потратил много времени, используя karma с Jasmine, хотя карма будет хорошо работать с другими наборами тестов, такими как mocha и qunit. Хотя они великолепны, и карма позволяет вам напрямую взаимодействовать с браузерами для запуска ваших тестов. Недостатком является то, что ваш тестовый набор становится большим, и он может стать довольно медленным.
В последнее время я перешел на Jest, который намного быстрее, и если ваше приложение для написания приложения использует enzyme с моментальным снимком дает вам действительно хорошее покрытие. Говоря о покрытии, Jest имеет стамбульское покрытие, встроенное и настроенное и издевательское, действительно прост в использовании. Недостаток его не тестируется в браузере, и он использует что-то, называемое jsdom, которое быстро, но имеет несколько неприятностей. Лично я не считаю это большой проблемой, особенно когда компилирую свой код через webpack/babel, что означает, что ошибки в кросс-браузере довольно незначительны и находятся далеко друг от друга, поэтому обычно это не проблема, если вы вручную проверите тест (и imo вы должны).
С точки зрения работы в стеке rails, теперь очень легко теперь, когда теперь доступен gp webpacker, и использование npm и node, как правило, гораздо более исключено. Я бы рекомендовал использовать nvm для управления версиями node
Хотя это не строгое тестирование, я бы также рекомендовал использовать linting, так как это также вызывает много проблем в вашем коде. Для JS я использую eslint с prettier и scss/css Я использую stylelint
В терминах того, что тестировать, я думаю, что, поскольку Карлос говорит о тестовой пирамиде, все еще актуально, ведь теория не меняется, просто инструменты. Я бы также добавил, чтобы быть практичным в тестах, я бы всегда тестировал, но какой уровень и охват будет зависеть от проекта. Важно управлять временем и тратить часы/дни на короткий проект жизненного цикла. Большие/долгосрочные проекты, преимущества большего набора тестов, очевидно, больше.
В любом случае, я надеюсь, что это поможет людям, которые рассматривают вопрос.