Меня зовут Семен, я занимаюсь автоматизацией тестирования мобильных приложений в hh.ru, и сегодня я расскажу о том, как писать автотесты под iOS. 

Быстрые регрессы, низкий time-to-merket, счастливые пользователи, у которых нет багов — для всего этого нам нужны автотесты. Наше мобильное приложение работает сразу на двух платформах, и мы пишем автотесты для каждой из них. 

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

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

Мы в 2ГИС придумали собственное решение — и уже четыре года проводим инженерные литературные клубы. Расскажу, что это такое и что мы получаем в итоге.

Хабр, привет!

Меня зовут Борис. Я Mobile AQA lead в Vivid Money.

Это вступительная статья в цикле статей по iOS-автоматизации, в которых я расскажу о том, как ускорить прохождение UI-тестов.

Данная статья будет полезна iOS-автоматизаторам с опытом, либо разработчикам.

В рамках этой статьи мы разберем такие этапы:

- зачем ускорять время прохождения UI-тестов;

- что такое Test runner, и какие они бывают;

- что нужно для прогона тестов без компиляции проекта;

- делимся опытом, как это помогает нам.

Всем привет, с вами я, Анна Жаркова, ведущий разработчик компании Usetech. 

Итак, долгожданная ежегодная презентация WWDC состоялась, мы готовы обсудить представленные новинки и анонсированные сессии. В этом году на Keynote основной упор был сделан на:

- игры и разработку

- иммерсивный звук и изображение

- многооконность

- расширенный и улучшенный шаринг, механизмы обмена самыми разными данными и совместные процессы, взаимодействие между устройствами

- улучшенные возможности отслеживать состояние здоровья и физическую активность

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

Сразу скажу, что все сессии упомянуть не возможно. В этом году их много, они довольно разнообразные и разноплановые. От улучшений уже известных нам фреймворков (SwiftUI, WidgetKit, SharePlay) до совсем новых (WeatherKit, ScreenCaptureKit). Также верно сказано, что описания сессий в этом году не сильно многословны, видимо, что подстегнуть зрителей к просмотру всех.

Учиться программированию — пожизненная затея. Почти всегда будет попадаться что-то новое, о существовании чего вы ещё не знали.

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

После разговора с @PrototypeAlex, где мы обсуждали множество этапов, которые проходят разработчики, у меня появилось вдохновение написать об этом. За 30 лет, которые я пишу код, я прошёл почти через каждый описанный в статье этап, и некоторые были особенно болезненными.

Узнаёте себя на каком-нибудь из этих этапов? И что я пропустил? Многие этапы ускользают из моего поля зрения; мы никогда не перестаём учиться и делать открытия.

Великий Копипастер

Писать код трудно, но люди решили проблему за вас! Ваш браузер переходит к Stack Overflow при вводе "s" в адресной строке, и вы часами вставляете различные фрагменты кода, чтобы увидеть, какой из них выполняет то, что вам требуется. Иногда это высасывает моральные силы, но в итоге у вас появляется хоть какой-то рабочий код.

Софт постоянно усложняется. Стабильность и простота расширения приложения напрямую зависят от качества кода.

К сожалению, почти каждый разработчик, и я в том числе, в своей работе сталкивается с кодом плохого качества. И это — болото. У такого кода есть токсичные признаки:

• Функции слишком длинные, и на них слишком много задач
• Часто у функций есть побочные эффекты, которые сложно определить, а иногда даже сложно отлаживать
• Непонятные имена у функций и переменных
• Хрупкий код: небольшая модификация неожиданно ломает другие компоненты приложения
• Плохое покрытие кода тестами или вообще его отсутствие

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

Однажды мой коллега уволился, потому что пытался справиться с REST API на Ruby, который было трудно поддерживать. Он получил этот проект от предыдущей команды разработчиков.

Исправление текущих ошибок создавало новые, добавление новых функций рождало новую серию ошибок, и так далее (хрупкий код). Клиент не хотел перестраивать приложение, делать ему удобную структуру, и разработчик принял правильное решение — уволиться.

Такие ситуации случаются часто, и это печально. Но что делать?