Зачем удалять идентификаторы QA из базы кода в производстве - PullRequest
Новая
       5

Зачем удалять идентификаторы QA из базы кода в производстве

0 голосов
/ 11 декабря 2018

В приложении React, которое мы разрабатываем, мы используем идентификаторы QA для тестов Selenium.

Неправильно ли оставлять их в базе кода в производственном (живом) режиме?

Если так, Зачем?Это только попытка поддерживать низкий TTFB (время до первого байта)?

Больше контекста:

  • Утилита для тегов автоматизации, которая принимает данную строку и возвращаетобъект, содержащий свойства для распространения на элемент.Их следует использовать только в целях тестирования, поскольку они должны быть доступны только во время выполнения теста.

Например. 

const automationTags = (givenTag) =>
  (IS_PROD || !givenTag) ? {} : { 'data-qa': _.kebabCase(givenTag) }

Использование:

  • <Component {...automationTags(`${dataQa}-button`)} />
  • <Component {...automationTags('profile-page-success-btn')} />

... где dataQa - опора, используемая в компонентах React.

1 Ответ

0 голосов
/ 12 декабря 2018

Я вижу ряд причин для того, чтобы оставить идентификаторы внутри.

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

  2. Это увеличивает точность между различными средами,Когда вы запускаете тесты автоматизации в своих тестовых средах, вы можете быть совершенно уверены, что это будет тот же код, который идет в производство, а не другой его вариант.

  3. Это позволяет вамзапустить автоматизацию против производственной среды.Вместо того, чтобы предполагать, что это работает после развертывания, теперь вы знаете, что это работает.Вы знаете, что они говорят о правильном предположении?

  4. Это не значит, что ваши клиенты могут злоупотреблять идентификаторами.Если ваши клиенты проверяют страницы / код, то просто знать, что идентификаторы элементов не являются вредными.

  5. Вместо того, чтобы включать конкретные идентификаторы QA, возможно, будет хорошей практикойпросто используйте фактические идентификаторы, имена классов и обычный CSS, чтобы вам не требовались конкретные идентификаторы QA

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

Сказав это, собственно измерение будет лучшим способом убедить разработчиков, что им не нужно их удалять.Например, в консоли разработчика Chrome есть способ измерить загрузку страницы и узнать, куда направляются ресурсы.Если вы перейдете в раздел «Производительность», вы можете записать загрузку страницы и посмотреть, что требуется для загрузки страницы.Сравнение производства с тестовыми средами должно дать вам больше информации.

...