У нас есть несколько приложений Angular (микроинтерфейсы), и все они на 100% покрыты нашими UAT (приемочными тестами пользователей), написанными с помощью Protractor (Angular Test Framework на основе Selenium).
Есть несколько проблем с этим подходом, хотя это, вероятно, лучший и рекомендуемый способ углового тестирования:
- Время отнимает ... Не поймите меня неправильно. Эти тесты очень удобны: всякий раз, когда мы вносим изменения, мы запускаем их (они на самом деле интегрированы в наши конвейеры CI / CD) и уверены, что приложение работает так, как нам хочется. Но, тем не менее, даже если мы все равно тестируем вариант использования как минимум 1 раз вручную, это также должно быть написано в Protractor / Jasmine. И требует времени ..
- Эти тесты очень зависят от структуры HTML. Некоторые локаторы находят html-элементы с xpaths (очень плохо), некоторые с id и т. Д., Но, в конце концов, любое изменение в HTML может как-то вызвать изменение в наших тестах ... хотя изменение ничего не меняет в пользовательском интерфейсе для конца пользователь.
- Весь CSS игнорируется. Как и типичные тесты Selenium, все тесты выполняются на DOM, и, кроме тестов, которые проверяют скрытые / показанные поля, более 90% нашего CSS игнорируется ... если однажды, одна строка, которая никогда не должна отображаться в 2 строки показано, действительно отображается в 2 строки, мы не будем знать, что автоматически.
Я представляю себе тестовый фреймворк, похожий на этот: вы открываете свое приложение в браузере и запускаете инструмент захвата клавиатуры / мыши вашего тестового фреймворка. Затем вы начинаете тестировать сценарий в своем приложении в браузере, например, перемещаете указатель мыши в определенном месте, нажимаете кнопку, выбираете значение из раскрывающегося списка, происходит перенаправление, и в конце вы смотрите на экрана и посмотреть, если нужный текст X отображается с правой стороны.
Единственное, что не может знать инструмент захвата, это то, что вы действительно проверили (X текст справа). Для этого вы делаете снимок экрана этой области и вставляете в свой тестовый фреймворк.
Эти захваты мыши / клавиатуры будут затем воспроизведены во время тестирования на конвейере, и проверки / утверждения будут выполнены на этих скриншотах ... возможно даже с некоторым смещением пикселя, если вы не хотите, чтобы ваши тесты проваливались в случае незначительных изменений CSS .
Будет ли это вообще полезно? Знаете ли вы, некоторые рамки, как это? Специально, что мы можем использовать для наших приложений Angular? Как вы думаете, этот подход лучше по времени и качеству?
Преимущества будут:
- Поскольку вы просто позволяете своему инструменту захвата работать, когда вы тестируете свое приложение сразу после того, как закончите реализацию, и делаете несколько снимков экрана и каким-то образом помещаете их в каркас, тесты не будут занимать так много времени, как написание кода для UAT.
- Они будут работать в основном независимо от структуры HTML. Поэтому, пока наша кнопка находится в своем местоположении и в своем поведении, она не будет беспокоить нас, если у нее теперь есть еще один родительский элемент в DOM.
- Наш Css также будет проверен, так как мы сравниваем фотографии.
- И, наконец, это именно то, что нам нужно: посмотреть приложение и посмотреть, правильно ли оно выглядит, щелкнуть и ввести некоторые события клавиатуры и еще раз проверить, видим ли мы то, что хотим. Не похоже на тесты на транспортир или селен, которые просто слепо общаются с DOM.