Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Частые ошибки при разработке фронтенда | OdessaFrontend Meetup #17

Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта?

Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Частые ошибки при разработке фронтенда | OdessaFrontend Meetup #17

  1. 1. Распространенные ошибки при разработке фронта Dmitriy Himenes Project manager
  2. 2. Кто я такой? ➢ Дмитрий Хименес ➢ Работаю в компании DataArt чуть больше года ➢ До этого более 10 лет занимался автоматизацией тестирования ➢ Преподавал на IT курсах ➢ Считаю, что если вы проучились 6 лет на врача, а потом решили стать Itшником, вашим пациентам очень повезло))
  3. 3. Агенда: • Как обычно разрабатывается фронт? • Почему нам важно тестировать наше приложение? • Кто должен сделать так, чтобы фронт был прост в тестировании? • Вы задумываетесь во время разработки, как будете тестировать фронт? • Несколько важных моментов о которых стоит помнить при разработке фронта. • Q/A.
  4. 4. Как обычно разрабатывается фронт? 
 ▪ Сейчас используют современные фреймворки: Angular, React, jQuery, Vue.js… ▪ Как часто вы пишете хорошие компонентные тесты? ▪ Пишите ли вы е2е тесты сами? ▪ Задумываетесь ли вы о тестировании, выбирая новый компонент для своего фронта?
  5. 5. • Unit тесты обычно покрывают один отдельный компонент, это может быть класс или набор классов, которые реализуют одну функциональность • E2e тесты подражают конечному пользователю и его действиям на вашем ресурсе Unit тесты VS e2e тесты
  6. 6. Почему нам важно тестировать наше приложение? 
 
 ✓ Сделать приложение стабильным ✓ Сохранить аудиторию для нашего ресурса ✓ Сохранить деньги ✓ Сохранить время ✓ Писать правильный и структурированный код
  7. 7. • Во первых это Вы! • Хорошо, если есть архитектор, который продумывает весь флоу и делает его консистентным • Стейкхолдеры! – Обычно им не интересно следить за правильностью написания фронта, пока не прилетают баги с продакшена • QAs, но только потому, что им нужно будет это покрывать тестами Кто должен сделать так, чтобы фронт был прост в тестировании? 
 

  8. 8. • Простой способ создать легко тестируемое приложение - это заставить разработчика писать на него тесты и мониторить результаты прогона • Но в более менее большом проекте это может занять «вечность» ☺ • Прежде чем добавить новый плагин или компонент в ваше приложение, узнайте, есть ли сложности с его тестированием и взаимодействием с этим элементом • Проектируйте ваше приложение так, чтобы у вас была логика использования, и в случае смены дизайна или фреймворка, вы могли сохранить логику, это поможет упростить повторное покрытие тестами Вы задумываетесь во время разработки, как будете тестировать фронт? 

  9. 9. Несколько важных моментов, о которых стоит помнить при разработке фронта 
 

  10. 10. • Все элементы с которыми можно взаимодействовать, должны иметь уникальный идентификатор, это может быть имя + имя конкретной формы, в идеале это ID • Это позволит нам проще взаимодействовать с формами, кнопками, списками и т.д.
  11. 11. • По возможности - не используйте бесконечные таймеры • Такой таймер распознаётся, как невыполненный скрипт и тесты могут ждать его выполнения часами…
  12. 12. • Сохраняйте логическую последовательность вашего приложения при обновлении дизайна или переходе на другой фреймворк • Это упростит переписывание тестов, а при полном сохранении логики, позволит их вообще не менять
  13. 13. • Подумайте, прежде, чем начать использовать новую технологию • Например: Использование Shadow-dom позволит вам инкапсулировать веб-элементы, но сделает процесс тестирования очень сложным, так как shadow-root элементы не видны на странице насквозь
  14. 14. • Всегда пишите Unit тесты, это сделает ваш код структурированным и консистентным
  15. 15. • Думайте о тестировании! • Каждый раз выбирая новый плагин или библиотеку, задумайтесь, нет ли там подводных камней? • Можно ли там использовать ID для элементов? • Есть ли у меня не уникальные элементы на странице? • Как я могу это исправить?
  16. 16. Ваши вопросы!
  17. 17. Dmitriy Himenes Skype: dima.himenes Telegram: @dima_himenes Спасибо за внимание!

    Be the first to comment

Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта? Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.

Views

Total views

56

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×