Брайан Брандес

Необходимые знания

Эта статья предназначена для программистов, которые пишут жасминовые тесты для приложений AngularJS, используя фреймворк для тестирования транспортир, построенный поверх selenium-webdriver.

Введение

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

Тем не менее, было бы немного нечестно, если бы я не упомянул, что добраться до этой точки — довольно возвышенная мечта. Это не легко; это связано с трудностями, как культурными, так и техническими. Между тем, чтобы заставить коллег-разработчиков в первую очередь писать тесты, не игнорировать и не отключать тестовые сбои, интегрировать тесты в конвейер сборки, запускать их в нескольких средах/браузерах и просто получать согласованные результаты, требуется много усилий, чтобы достичь тестирования Нирваны. До тех пор, пока вы не создадите прочную культуру тестирования, любые существующие усилия по тестированию будут слабыми и непродуманными, уязвимыми для провала и гноения в долгосрочной перспективе.

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

Проблема противоречивых тестов

*Что вы могли иметь в виду под противоречивыми результатами теста?*

Возьмите этот распространенный сценарий: вы запускаете тест один раз, и он терпит неудачу. Но затем вы повторно запускаете его один, два, десять раз подряд, и каждый раз он проходит.

Для некоторых это просто небольшое неудобство. Но на самом деле это нетривиальные затраты, которые могут привести к некоторым довольно коварным проблемам, две из которых:

  1. Вы задерживаете процесс сборки
  2. Вы подрываете доверие к тестам

Чтобы добавить немного контекста, вот общий обзор того, как наши автоматизированные тесты выполняются здесь, в Nitro:

  1. Новый код регистрируется в основной ветке
  2. Jenkins (наша система непрерывной интеграции) обнаруживает эту модификацию версии системы управления версиями и перестраивает среду тестирования, используя последний код.
  3. После завершения комплексный набор тестов отправляется в saucelabs.
  4. Тесты выполняются параллельно в нескольких браузерах (и операционных системах).
  5. По результатам набора тестов сборка помечается как пройденная или не пройденная.

* Только сборки, помеченные как пройденные, могут быть переведены в рабочую среду.

Вначале мы поняли, что наше решение для тестирования было довольно ненадежным из-за проблем, возникающих на шаге № 4. Часто наши сквозные тесты выполнялись в нескольких браузерах, один единственный тест в одном браузере завершался сбоем, в результате чего вся сборка помечалась как неудачная. При расследовании проблемы часто были разовыми, случайными, например, сторонняя библиотека не загружалась, служба была временно недоступна, конфликт из-за случайно сгенерированных конфликтов адресов электронной почты или тайм-аут теста, потому что он выполняется очень быстро локально, но медленно на соусе. .

Обычно повторное выполнение сквозных тестов обычно решало проблему, но если возникала еще одна спорадическая ошибка, мы снова оказывались в той же проблемной ситуации. Весь набор тестов выполняется в

protractor-flake –maxAttempts=10 — protractorLocalChrome.js –specs=randomFail.js 
Using the selenium server at http://localhost:4444/wd/hub [launcher] Running 1 instances of WebDriver
Started
Failures:
1) Given a flakey test it should randomly fail, 75% of the time
Message: Expected 3 to be 1.
Stack:
Error: Expected 3 to be 1.
1 spec, 1 failure
Re-running tests: test attempt 2
Re-running the following test files:
/Users/bbrandes/Desktop/nitroapps/account-portal/randomFail.js
Failures:
1) Given a flakey test it should randomly fail, 75% of the time
Message: Expected 3 to be 1.
1 spec, 1 failure
Re-running tests: test attempt 3
Re-running the following test files:
/Users/bbrandes/Desktop/nitroapps/account-portal/randomFail.js
[launcher] Running 1 instances of WebDriver
Started
1 spec, 0 failures
Finished in 0.086 seconds
[launcher] 0 instance(s) of WebDriver still running
[launcher] chrome #01 passed

Как вы можете видеть в приведенном выше журнале, тест не прошел первые два запуска, но третий раз был волшебным, и весь набор тестов был отмечен как пройденный. В случае, если ему не повезет и он потерпит неудачу 10 раз, весь набор будет помечен как неудачный.

Заключительные мысли

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

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