t.me/atinfo_chat Telegram группа по автоматизации тестирования

Рефакторинг Java-кода (Selenium WebDriver)

refactoring
java
selenium
Теги: #<Tag:0x00007f9c464d2788> #<Tag:0x00007f9c464d25f8> #<Tag:0x00007f9c464d24b8>

(Nikita Milaserdov) #1

Всем привет. Только начинаю писать автотесты на Java. Но, как сказали у нас в компании, то скоро будут проверять код.
Есть ли какие-либо best practices для рефакторнга кода?
В данный момент я только обучаюсь, поэтому у меня самые простые кейсы, типа залогинься, проверить данные и т.д.


(Sergey Korol) #2

Прежде чем что-либо рефакторить, надо для начала чему-то научиться. :slight_smile:
Рефакторинг, как правило, проводится в нескольких случаях:

  • Человек намеренно писал на скорую руку, чтобы выкатить прототип. При этом, будучи уверенным, что в дальнейшем это обязательно трансформируется в tech debt, который будет непременно закрыт. Все это естественно честно озвучивается заказчику, мол: “смотри при твоих хотелках, дедлайнах и доступных ресурсах, я могу сделать вот так, но это будет какашкой. Если не хочешь, чтобы потом эта какашка развалилась по всем известным причинам, надо будет выделять время на рефакторинг”. Ну и конечно же при таком кейсе заказчику сразу предоставляется выбор - делаем либо быстро, но плохо, либо хорошо, но долго. Когда это становится выбором заказчика, то потом он уже не отвертится.
  • Человек писал, как умел. Но за какой-то период научился чему-то новому (умные книжки, курсы, пет проекты, whatever). И вот, глядя на свой предыдущий код через время, он начинает осознавать, что и как можно было бы переписать, исходя из своего свежего взгляда и приобретенного опыта.
  • Человек сознательно придерживается подхода - “вначале сделать, чтобы работало, затем сразу отрефакторить”. При этом, он уже сейчас обладает нужными скиллами, чтобы это сделать.

Ваш кейс пока не попадает ни под один из пунктов. В последствии вы скорее всего придете ко второму. Но на текущий момент, нельзя просто взять, почитать какие-то best practices, и сразу начать писать лучше, чем было. Для осмысления чего-то нового нужно много практиковаться: читать и писать код. А это невозможно без фундаментальных знаний в программировании. Задавали ли вы себе вопрос - а насколько хорошо на текущий момент вы знаете, к примеру, java core? Только изучив основы, вы сможете хотя бы отдаленно начать воспринимать паттерны проектирования и best practices в написании кода.

П.С. Под проверкой кода скорее всего подразумевалось подключение средств статического анализа. Соответственно, наименьшее, что вы сейчас сможете сделать, - это добавить соответствующие тулы первыми, и пофиксить все проблемы. Ну а дальше - учиться и еще раз учиться. Поскольку на code review все ваши “best practices” сразу же повсплывают на поверхность. :slight_smile:


(Павел) #3
  1. Почитайте литературу:
  1. Много практикуйтесь - пишите код, читайте код (свой и чужой), переписывайте старый код, так сказать, “набивайте руку”. Не нужно бояться написать что-то кривое или страшное, попробуйте следовать подходу: рабочее решение > оптимальное > красивое.

И самое главное: по затраченному времени, написание кода << чтение кода, поэтому всегда старайтесь в итоге работы получить читабельный код, с которым други люди смогут нормально работать, а не тот код который бездумно следует каким-то конвеншнам/правилам итд.


#4

cto pod etim podrazumevaetsia?


(Nikita Milaserdov) #5

Нет) Я сам QA, а проверять будет Test Automation Lead


(Sergei) #6

Качество кода в автоматизации зачастую гораздо ниже чем в разработке да и задачи не рокет-сайенс, так что не стоит особо переживать, даже если проверять будет сам Test Automation Lead. Да и по-хорошему его задача не загнобить, а помочь быстрее развиться в спеца, приносящего профит компании :slight_smile:


#7

Никита, если говорить о рефакторинге, то могу посоветовать https://seleniumjava.com/category/code-refactoring/ и https://refactoring.guru/refactoring (2-ой имеет версии українською и по-русски). Там очень хорошие объяснение, что к чему :slight_smile:

Но, наверное, в вашем случае надо смотреть на automation best practise - как писать хорошие локаторы, названия тестов, и т.д. Я накинула на коленке все, что мне наиболее часто приходилось исправлять после review моего кода . Надеюсь, вам это хоть как-нибудь поможет
http://listmoz.com/view/J3DHdMPCJxfTFfHJ5fs

Ну и так, навскидку, есть хорошие видео по этой теме:

  1. Типичные ошибки начинающих писать тесты на WebDriver
  1. Everything you want to know about Page Object design pattern (Mikalai Alimenkou, Ukraine), part 1
  1. Статьи
  1. Алексей Баранцев: Десять правил построения хороших локаторов

Очень надеюсь, что если вы научитесь чему-то новому или у вас будет собственная шпаргалка по рефакторингу, вы поделитесь этим с новичками, так как для начинающих действительно мало структурированной информации.

Успехов вам :wink:


(Vjacheslav Lukashevich) #8
  1. По хорошему у каждого рефакторинга должна быть конкретная цель - улучшить читаемость, развязать сложно написанный код, привести к общему стилю, улучшить стиль кода, починить антипатерн (тут на сайте можно как раз прочитать).
    Просто так рефачить без цели плохая идея.
  2. Удобно рефакторить небольшими понятными кусками и запускать до и после тесты
    Мне нравится эта статья
    https://www.sitepoint.com/technical-debt-rescuing-legacy-code-through-refactoring/

(Женя Воронкин) #9