Flutter Enthusiast
За пару недель этого года мы поделились подборкой обзоров наушников, рассказали о попытках сохранить звуки старых модемов, обсудили «худшие» музыкальные треки и несколько других тем: от старого железа до «ASRM на питлейне». Сегодня продложаем говорить о примечательных полочниках и портативной акустике.
Перед вами очередное руководство по Mockito. В нём я, с одной стороны, попытался описать функционал этой библиотеки так, чтобы незнакомый с нею читатель сразу получил возможность полноценно ею пользоваться, а не только общее представление о ней. С другой — я хотел сделать его достаточно компактным и структурированным, чтобы можно было быстро прочесть его целиком и быстро найти в нём что-то единожды прочитанное, но подзабытое. В общем, эта такая статья, какая бы пригодилась мне самому, когда я только столкнулся с этой библиотекой и не очень понимал, как она работает.
Полагаю, она и сейчас может пригодиться мне же — иногда я забываю что-то из этого, а вспоминать материал удобнее всего не по официальной документации или чужим статьям, а по собственному, скажем так, конспекту. Вместе с тем я старался построить текст так, чтобы он был удобен прежде всего для знакомства с Mockito с нуля, и кое-где подробно разбираю вроде бы очевидные вещи — не все из которых были для меня очевидными с самого начала.
Как оценить технический долг и получить разрешение на его починку, прежде чем он поглотит вас и вашу команду? Этот вопрос рано или поздно встает перед всеми лид-разработчиками. Но его решение требует большой экспертизы и грамотного анализа. Поэтому давайте вместе разбираться, как лучше искать, извлекать и обеспечивать техдолг, а заодно выясним причём тут слоны.
Праздничные дни для Додо Пиццы — настоящий хайлоад. К ним мы готовимся заранее и заводим специальные правила.
Самое жаркое время — в декабре: много корпоративов, заказы становятся больше, прибыль выше. Во многих городах плохая погода — где-то выпал снег и дороги не расчищены, где-то очень холодно. Всё вместе это создаёт нагрузку и на IT, и на бизнес. От нагрузки может сломаться что угодно: то очередь задач переполнится, то печь выйдет из строя. Чтобы быть готовыми, мы регулярно проводим нагрузочные тестирования, повышаем закупки ингредиентов, распределяем заказы по пиццериям и много чего ещё.
Для мобильных разработчиков конец года раньше тоже был особенный: с 23 по 27 декабря App Store закрывался на рождественские праздники, приложения не проверялись, опубликовать что-то было невозможно.
Расскажу, как влияют эти ограничения на разработку, какие ошибки мы совершили в прошлые годы и что меняется в расписании. Возможно, что-то из практик пригодится и вам: подсветит риски, поможет договориться о код-фризе с бизнесом.
Проверка кода (code review) — отличный инструмент для повышения качества кода, но он не учитывает один факт: отправляют и просматривают код люди, а они устают, теряют сосредоточенность, ленятся, да и просто испытывают эмоции в самые неожиданные моменты.
Поэтому хочу представить свое видение хороших и плохих практик код ревью с учётом человеческих особенностей.
Эта статья является переводом материала «When to Mock».
Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».
Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. У нашей команды есть влог на ютюбе, где мы рассказываем о том, как разрабатывается наша мобилка. Теперь мы начинаем рассказывать еще и о том, как все эти разработки тестируются. Для заинтересованных мы создали отдельный плейлист, в котором будем рассказывать о тестировании и автоматизации.
В этой статье мы отвечаем на 5 самых популярных вопросов ручных тестировщиков про автоматизацию. Видеоверсию можно посмотреть тут.
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Ранее мы уже выпустили статью с ответами на вопросы ручного тестировщика про автотесты (а также в формате видео). Продолжаем серию ответов: в этой статье мы ответим на 5 самых популярных вопросов менеджера про автотесты. Расскажем о том, сколько времени и ресурсов будет потрачено на автоматизацию, и как скоро она начнет приносить пользу. Видеоверсию можно посмотреть тут.
Если вы работаете в IT, то о легаси вы слышите часто — обычно с множеством негативных коннотаций. Понятно, что это не «хороший код», но какой? Может старый, может не поддерживаемый или не обновляемый, а может просто чужой? Есть ли «полноценное» определение «легаси», на которое можно ссылаться? А когда разберемся — что нам делать с легаси? Попробуем разобраться.
Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе «Инженер по тестированию», поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.
В эпоху вселенского внедрения agile-методологий и Devops уже никто не сомневается в том, что регрессия должна быть автоматизирована. Особенно, если в компании идет речь о Continuous Delivery. Все кинулись хантить разработчиков автотестов, от чего рынок становится перегретым.
В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum. И все эти agile-ы и devops-ы можно внедрять и без этих людей. Так что если кто-нибудь вам скажет, что у них в команде все тестируют руками — потому что у них по каким-либо причинам нет разработчика автотестов — не верьте им. Они тестируют руками, потому что по-другому им лень. Или не умеют.
Любите ли вы KPI? Полагаю, скорее всего, нет. Трудно найти человека, который не пострадал от KPI в том или ином виде: кто-то не дотягивал до целевых показателей, кто-то столкнулся с субъективной оценкой, а кто-то поработал, уволился, но так и не смог узнать, из чего состояли те самые KPI, которые в компании даже упомянуть боялись. И вроде бы хорошее дело: в показателе тебе транслируют цель компании, ты делаешь всё для её достижения, в конце месяца получаешь премию или другой бонус. Прозрачная игра, честные ставки. Но нет, KPI превратились в страшного и неудобного монстра, который то и дело норовит подстегнуть нерадивых, но при этом ничего не даёт исполнительным сотрудникам. Что-то с этими показателями не так!
Спешу сообщить: если вы не любите KPI, в вашей компании их просто не умеют готовить. Ну или вы разработчик.