Подашел или подошел как пишется

Если вы когда-либо занимались автоматизацией тестирования веб приложений, то скорее всего у вас возникал вопрос: какой же он – идеальный фреймворк? И как выбрать наиболее удобный инструмент позволяющий быстро и качественно оценить результаты работы автотестов?

Ответ прост, как и на вопрос «сколько будет дважды два?». Кто ответил «5», «7» или «2» смело продолжайте читать этот пост. А кто ответил «4» тем более может найти здесь для себя что-то полезное. В этой статье вы не увидите ни строчки кода, только мои впечатления от знакомства с JDI фреймворком и облачной платформой для запуска тестов SauceLabs. Вот она интрига, итак, поехали…

Ближе к теме. Я работал некоторое время на проекте с использованием Selenium WebDriver в качестве базы для построения тестового фреймворка. Также применялся неплохой инструмент собственной разработки, анализирующий результаты прогона тестов с широким функционалом. Тесты запускались удаленно на виртуальных машинах, под которые был выделен специальный сервер. Не вдаваясь в подробности того, как все было устроено, использование WebDriver для написания тестовых сценариев на практике помогло мне обратить внимание на множество нюансов, без хорошего понимания которых легким движением руки фреймворк может развалиться как карточный домик. Другим необходимым навыком для автоматизатора является не только способность написать стабильный тест, но и в случае его падения, быстро разобраться с причиной, чтобы дать актуальный и по возможности однозначный фидбэк команде разработчиков. Или же внести правки в сам падающий тест. Тут нужно и понимание логики работы тестируемого приложения, и грамотная настройка логирования и конечно же возможность просмотреть историю результатов прогонов автотестов за некоторый период времени.

Разбирая впоследствии проектное приложение по кирпичикам и собирая заново как конструктор Lego все постепенно встало на свои места. Казалось-бы, чего проще, используй аналогичную модель на других проектах и будет тебе счастье. Но в IT, на мой взгляд, так не работает. Будучи в этой сфере, ты постоянно находишься в поиске и открываешь для себя новые технологии. И буквально две недели назад я столкнулся с альтернативной базой построения тестового фреймворка под названием JDI. А точнее, JDI-light, написанный поверх WebDriver. Первым вопросом что пришел мне в голову был – «зачем?». Зачем дополнительная прослойка между мной как тестировщиком и довольно неплохо зарекомендовавшим себя инструментом от Selenium?

После небольшого погружения в JDI, мой ответ будет следующим: если технология позволяет с минимумом затрат и усилий на ее внедрение выполнить одну и ту же работу эффективнее, то она имеет право на существование. Более того, на рынке выживает тот, кто может быстрее адаптироваться к новым условиям. Но нельзя сбрасывать со счетов и тот факт, что каким бы современным ни был молоток, но если начать забивать им не гвозди, а к примеру шурупы, то это будет как минимум менее эффективным по сравнению с применением шуруповерта.

Ну и резонный вопрос: насколько же просто начать использовать JDI?

1. Если проект новый, то просто подключаем зависимости на jdi-light, на тестовый фреймворк (testing, junit) и инструмент для репортинга в зависимости от предпочтений. И у нас по дефолту уже будет готовый к использованию веб драйвер (chrome), а также за нас реализованное, приятное глазу логирование. Более тонкие настройки можно сделать, раскомментировав или заменив дефолтные значения в проперти файле.
2. Если проект уже некоторое время существует, то нужно заменить зависимость selenium на jdi-ligh и если у вас применяется паттерн PageFactory, то потребуется в коде заменить импорт этой фабрики с selenium на jdi. Но здесь обольщаться не стоит. Да проект может даже запуститься с первого раза, но, чтобы получить все бенефиты, которые предоставляет JDI придется еще изрядно потрудиться, но это уже тема для другого поста.

Кроме этих действий потребуется немного перестроить свое прежнее видение того, как описывать веб элементы, сами страницы и конечно же как оформлять сами тестовые сценарии. Исходя из своего опыта могу сказать, что мне на это потребовалось 3-4 дня с беглым просмотром документации и оказалось довольно просто и даже приятно.

Кого-то может расстроить введение дополнительной типизации веб элементов. Но JDI типизация дает ряд преимуществ: от сокращения в разы количества набираемого кода и соответственно улучшения его читаемости до предоставления широкого набора дополнительного функционала «из коробки», который ранее приходилось также самому имплементировать в объектах представлений страниц. А если вдруг понадобиться определить свой пользовательский тип или дописать какие-то хитрые действия с элементом, то механизм наследования и полиморфизм в данном случае все также продолжают работать.

Перечисление фишек и плюшек JDI можно продолжать еще очень долго, но не будем заострять на этом внимание, так как документация с примерами использования и шаблонами проектов для старта представлена на github в довольно удобном для восприятия виде.

И еще один лайфхак. Взаимодействие с различными инструментами также просто настраивается, как и легко интегрируется Selenium WebDriver с, например, Selenoid, BrowserStack, Applitools или SauceLabs. В общем, пока одни плюсы.

Я, собственно, так же недавно поближе смог познакомиться с возможностями, которые предоставляет SauceLabs и могу отметить их привлекательность, хотя пробный бесплатный период его использования длится всего две недели и существует ограничение по общей длительности запускаемых на сервисе тестов (1ч 35 мин). Есть еще один минус, связанный с довольно частыми проблемами при регистрации пользователя на указанном ресурсе. Я также столкнулся с подобной коллизией, однако, короткая переписка с представителем техподдержки помогла-таки воспользоваться бесплатным тестовым периодом.

SauceLabs предоставляет обширную коллекций конфигураций операционных систем, браузеров и устройств. В документации заявлено, что при наличии правильной многопоточной конфигураций тесты будут выполняться параллельно в пакетах по 18 тестов за раз, планируя новый пакет каждый раз после его завершения. К тестам пишется лог, делаются скриншоты и видео. Говорится о возможности запустить, к примеру, упавший тест в ручном режиме. Но у меня это не получилось, вероятно, эта возможность появляется только после приобретения подписки.

И как же подключить JDI проект к SauceLabs? Очень просто. Зайти в проперти файл и раскомментировать одну строку ‘remote.type=sauce’, это если указанное вами месторасположение при регистрации в SauceLabs обрабатывается европейским датацентром. А если американским, то в том же файле раскомментировать еще одну строку ‘driver.remote.url’ и заменить url на тот который будет указан в вашем SauceLabs профиле. Если не хотите хардкодить свои данные для доступа к ресурсу в самом проекте, то следует назначить две переменные окружения SAUCE_USERNAME и SAUCE_ACCESS_KEY, значения которых также можно найти в своем профиле. И все, теперь можно в своей любимой IDE нажать кнопку старт и увидеть прогон тестов в онлайн режиме. Или же, попросить maven запустить нужные тесты, передав ему в качестве параметров командной строки – DSAUCE_USERNAME={username} – DSAUCE_ACCESS_KEY={accessKey}.

На этом мой обзор JDI и его интеграции с Saucelabs подошел к концу. Какой вывод я сделал для себя: не бывает идеальных инструментов, но есть те, которые в определенных обстоятельствах могут значительно облегчить труд программиста. И я добавил JDI в свой набор претендентов на то, чтобы быть предложенным будущему заказчику проекта для автоматизации тестирования. Saucelabs, как готовой сервис облачного тестирования, теперь так же будет находиться в моем поле зрения.

Полезные ссылки:

JDI проект
Шаблоны для быстрого старта
Примеры использования
Документация
Документация

Я прошел за свою деятельность больше 100 собеседований на позиции Senior Java Developer, и скажу я вам, накопилось много интересных моментов, которыми и хочется поделиться.

К слову, я не махровый кодер, в разработке около 5 лет, на позиции Senior всего 2,5 года. Понятие о Senior у всех разное, но в моей конторе, я именно Senior и в предыдущей тоже таковым обзывался. Но это не исключает того, что я могу быть неопытным мидл разработчиком с ЧСВ от архитектора, который накидал однобокий и токсичный текст ?

Прежде всего, цель статьи выплеснуть накопившиеся эмоции. Да вот так просто.

Ну и конечно, будет собеседующимся ощущение, что не только у них так бывает. Для интервьюеров, которые прочтут эту статью, она может дать возможность призадуматься, а то и скорректировать свои вопросы и подход к собеседованию.

Давайте ближе к делу.

Хотел бы разбить по категориям наших любимых интервьюеров (сортировка от отстоя к классным).

1. Ленивец

Их метод прост как пробка — берем список вопросов и ответов из различных статей (как подготовится к собеседованию по Java). Обычно у таких проходишь собес на раз два. Однако, есть и подводные камни — некоторые такие деревянные, что могут, сверяя ваш ответ с тем, что на бумажке, не понять, что это одно и тоже. Попросту они не всегда могут смапить ответ на бумажке и ваш ответ. Редко, но все таки.

У такого подхода есть только один плюс для интервьюера — не надо долго готовиться и вырабатывать свою методу. В остальном — печаль.

2. Теоретик

Этот класс особо любим, но встречается редко. Здесь во главе угла чистейшая теория по Java Core, причем до каких то извращенных деталей, которые, по моему мнению, ну совсем не нужны в моей памяти.

Вопросы могут быть такими: — назовите все примитивные типы в Java, сколько каждый тип занимает памяти, если не помнишь, то посчитай; — какие методы класса Object, стандартный вопрос (многие задают), но в данном случае нужно назвать все до одного, т.к. собеседующий реально за это запаривается и сидит считает.

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

Здесь тоже плюсов особо нет, они ушли не далеко от ленивцев.

3. Мистер алгоритм

Ну из названия почти все понятно. Некоторые насмотрелись бест оф зе бест практис и решили перенять их ?

В основном это решение алгоритмических задачек онлайн в напряженной атмосфере. Здесь обойдусь без комментариев — сами решайте, что по этому поводу думать.

Сюда же отнесу, да простит меня Java сообщество, «зануд» или «ярых программеров». Это люди увлеченные функциями, алгоритмами, формулами, в целом математикой, и прочими университетскими штучками. Такие люди готовы искать лучшее решение задачек в свое свободное время, вместо развлечения или отдыха.

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

4. Лайв кодер

Здесь часто могут попросить написать тот или иной код в блокнотике расшаренном. Например: давай напиши синглетон, напиши какой-нибудь класс с функцией такой то и такой, напиши апи без логики, именно контракт и прочие.

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

Что же касается интервьюеров, то у них могут быть разные заскоки, которые не вяжутся с адекватностью.

Кто-то будет запариваться за синтаксис, за пропущенные кавычки, скобки, модификатор. Пишешь ты код на вскидку, потом местами его корректируешь (меняешь названия, модификаторы, типы данных, в общем много чего) и рождается что-то, что ты готов отдать на ревью собеседнику. И тут начинается… где-то что-то не дописал, забыл поменять при переписывании. Ну здесь сразу провал и лишение всех сеньорских титулов — ведь ты даже основ Java не знаешь раз забыл элементарщину.

Кто-то будет докапываться до реализации, мол подразумевалась доп. логика, на что ты аргументированно ставишь человека на место, он соглашается, но осадок остался о тебе как о неприятной личности (тоже провал).

Плюсы есть: реально посмотреть на то как пишешь код, как логику строишь, как проектируешь (используешь или нет паттерны). Главное, ребята — без фанатизма. Не надо докапываться до ерунды.

5. Крутые ребята

Начинают с основ, быстро проходят за 5 мин, понимают, что не джун.

Далее GC, память JVM. Потом вопросики поинтереснее про Spring и его работу, паттерны, SOLID. Потом БД. Понимают что точняк мидл, авось и более.

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

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

Итого для собеседующихся

1. Не переживайте, если вас недооценили — это нормально. Главное чувствовать свой уровень. На отказы реагируйте спокойно, просите пояснить чем не подошли, делайте выводы.

2. В целом любой собес — это прокачка узких мест, понимание своих пробелов. А это значит, что есть куда расти и вам указали точки роста.

3. При поиске работы, общении с эйчарами и собеседованиях, вы оттачиваете способность себя продавать на рынке труда. Рынок есть рынок. Нужно знать свою цену на текущий момент. Периодически похаживайте по собесам — будьте в тонусе и в цене ?

4. Не скромничайте по цене. Если не хотите долго искать — просите 300К. Если есть месяц походить на собеседования, то берите 350К — 400К (правда некоторые захотят, чтобы за эти деньги вы умели летать и стрелять лазером из глаз). В Java на ноябрь 2021 года по Москве(или удаленка) вилка для Senior 300К — 400К руб. К чему я это, некоторые достойные люди, хорошие разработчики, просят по 250К — 300К, хотя рынок поменялся, инфляция колоссальная, недвижка выросла в 1.5-2 раза… ну вы поняли — выросли цены, и ЗП тоже должна подрасти (все по честному).

Итого для интервьюеров

1. Посмотрите немного со стороны на ситуацию, вспомните свои собеседования, где вы были собеседующимися.

2. Определите для себя, что критически важно именно для ваших задач:

   • усиленное знание БД

   • знание инфраструктуры и девопсерство

   • алгоритмы

   • жестокая многопоточка, которая у вас используется на каждом шагу

   • понимание архитектуры как приложения, взаимодействия между системами

     Можете об этом сразу сказать собеседнику при начале собеседования, что именно вот это у вас критически важно.

3. Не запаривайтесь за мелочевку, особенно если при дополнительном вопросе человек вам ответил как надо. Вы же не робота собеседуете, каждый может опечататься, забыть что-то, просто растеряться.

4. Если человек не подошел по цене, так и скажите честно: «Все норм, но за эти деньги мы хотели больше опыта». Возможно предложить чуть поменьше, т.к. собеседующемуся может понравился ваш проект или команда.

Пишите интересные истории из своих собеседований в комментариях.