А всё таки, когда моки зло, а когда нет?

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

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

Последний случай, описывает процесс мокирования. То есть мок, это когда мы проверяем то, как код что-то делает, а не что он делает. Иногда говорят, что мы тестируем методом white-box, потому что мы знаем как конкретно написан тест и завязываемся на это, а не на результат работы этого кода, как в black-box тестировании.

Когда мы проверяем как код работает, мы связываем тест с внутренней реализацией. Любое изменение внутри функции (например, вызов другого метода или смена порядка действий) может поломать тест, даже если внешнее поведение программы остаётся тем же. В итоге тест перестает быть защитой от ошибок и превращается в тормоз для рефакторинга. В подкасте про спринг я услышал классный термин: "бетонирование кода", вот это оно и есть.

Когда же моки все таки нужны? Допустим мы пишем систему с поддержкой хуков, например фреймворк для тестирования. В тестах такого фреймворка вполне допустимо проверить что хуки setup, teardown, beforeSetup, afterSetup и так далее, вызываются в нужном порядке и с нужными аргументами.

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

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

Например:

- Фейковая база данных, которая хранит данные в памяти.
- Фейковые сервисы какого-нибудь облака, например AWS
- Поддельный HTTP клиент, который возвращает заранее заготовленные ответы.
- Заглушка почтового сервиса, которая записывает письма в список, а не отправляет их.

Все эти решения делают тесты быстрыми, предсказуемыми и независимыми от инфраструктуры, при этом вы все еще проверяете поведение системы снаружи, не нарушая принцип black-box.

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

Итого

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

Ссылки: Телеграм | Youtube | VK

У меня сегодня с утра был созвон с разработкой Хекслета, где мы обсуждали разные задачки и там всплыла такая история. К разработке пришли ребята из b2b с просьбой. Говорят, что есть клиент, который сейчас должен оплатить подписку для b2b (она немного отличается от b2c подписки), но есть моментик. Они покупают много, поэтому им согласовали скидку на стоимость подписки.

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

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

Я как-то тоже сначала включился в обсуждение реализации, а потом сказал, погоди, мы же на счет закидываем деньги сами. Кто нам мешает закинуть больше денег не меняя ничего? Это еще можно и красиво завернуть, что при пополнении на столько-то, вот вам бонус. И вообще ничего не придется менять. На этой позитивной ноте мы и разошлись, а разработчик пошел с решением к b2b :)

Ссылки: Телеграм | Youtube | VK

Сложность обучения

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

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

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

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

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

В сухом остатке получается, что лучше делать проще и получать скучающих профи, чем делать сложно и получать по щщам от начинающих. До определенного момента конечно.

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

Все это конечно не отменяет, что сам материал никогда не написан идеально и должен постоянно дорабатываться :)

Ссылки: Телеграм | Youtube | VK

Пропускаем выпуск

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

Сегодня воскресение, поэтому без кода и технических тем. Расскажу немного про погоду и почему я переехал :)

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

Первый раз выехать туда получилось в 2014 году, тогда у меня уже появился ребенок, поэтому мы смогли заценить как это, когда не надо надевать на себя 10 слоев одежды. Жили кстати на Пхукете, он довольно круто прокачен в плане детских штук (в эту же поездку я встречался с девелоперами Aviasales там же). Спустя несколько лет мы пожили в Паттайе и даже в Малайзии, в городе с красивым названием Петалинг Джая.

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

Буквально через полгода после той поездки в тай, мы смогли съездить в штаты. Я тогда удачно продал машину и у меня возникло дикое желание прокачать английский. Поэтому я оформил себе учебную визу и поехал в Санта Монику (один из городов Лос Анджелеса) учиться. План был такой, я на месте осматриваюсь в течение месяца, а потом приезжает моя семья. Всего на поездку заложили полгода. Именно тогда я написал первую версию кодбатла на эрланге :)

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

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

Тогда я начал поиски, а куда можно податься? Оказалось что у школы есть филал в Майами и там купаться можно круглый год благодаря гольфстриму. Хотя все люди с которыми я это обсуждал, отговаривали меня, говорили что Майами так себе место. В общем я быстро оформил все что надо и улетел.

Первое впечатление в Майами меня испугало. Слишком жарко, везде бегают ящерицы, вокруг какая-то разруха. К счастью последнее оказалось просто неудачным местом. Потом я переехал в город Sunny Isles Beach и прожил там еще 5 месяцев вместе с женой и дочкой. Кстати, таки заговорил на английском, пробил какой-то барьер.

И вот в 2019 году мы переехали сюда окончательно. Причины было три: инфраструктура, английский, климат (с возможностью постоянно купаться). Как оказалось, в мире таких мест кроме Майами то и нет особо.

Многие думают, что Майами это что-то типа Тая по климату. Вообще не так. Например два дня назад утром было 6 градусов. Зимой ночью бывает и минус. Климат в майаме такой что с октября по март погода как в Калифорнии. Днем тепло, дождей нет (они в сентябре начале октября), утром и вечером достаточно прохладно, вплоть до того, что приходится надевать джинсы и ветровку. Я так понимаю что пришла зима :) Со стороны это может показаться смешным, но когда проходит 3-4 года, ты начинаешь острее чувствовать такие переходы, хотя первые годы, я боялся конца лета, всегда было ощущение, что щас будет слякоть, тьма и противные дожди.

Да летом жарко, но лучше мы летом куда-нибудь уедем (как тут все и делают), зато остальное время кайф. Такие дела :)

Ссылки: Телеграм | Youtube | VK

Полезные ресурсы

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

1. https://github.com/Hexlet/ru-test-assignments - самый большой сборник тестовых заданий от разных компаний. Через них и на компании выйти легче и попрактиковаться не грех. Кстати, если там нет вашей компании, то пулреквест может это исправить :)

2. https://github.com/Hexlet/ru-projects-for-contributing - список опенсорсных проектов, в которых можно участвовать чтобы нарабатывать опыт. Речь идет не про библиотеки и какую-то мелочь, а про законченные проекты для конечных пользователей типа Code Basics.

3. https://github.com/Hexlet/ru-interview-questions - список вопросов с реальных собесов по куче направлений и уровню.

4. https://github.com/Hexlet/ru-local-communities - список локальных сообществ по городам. Сейчас это чаще онлайн, но есть и офлайн

5. https://codebattle.hexlet.io/ - один из самых больших и значимых проектов Хекслета. Кодбатл это место, где в реальном времени можно на скорость решать задачи с другими людьми, по принципу PvP. Проект пользуется популярностью по всему миру

Все это опенсорс, в котором можно и желательно участвовать :)

Ссылки: Телеграм | Youtube | VK

Нужно ли писать сопроводительные письма? Одни говорят, что да обязательно, другие, что их никто никто не смотрит. Но говорить это одно, а делать другое. Мы тут решили выяснить, а как оно происходит на самом деле. Для этого мы опросили больше сотни разработчиков и рекрутеров, собрали все вместе, проанализировали и записали это видео, где все разложено по полочкам. Приятного просмотра, не переключайтесь 🙂

https://www.youtube.com/watch?v=ZaASNKUgHx8

Почему нужно использовать DTO

Data Transfer Object, термин, который для разработчиков на статических языках является чем-то самим разумеющимся, но вот остальные его могут не знать (даже если пользуются). Хотя в эпоху интеграций, фронтенд-бекенд, сервис-сервис, очереди, это крайне важная конструкция.

DTO это очень промежуточный объект между моделью в вашем коде и данными, которые вы отдаете наружу или принимаете от внешней системы.

⁃ Модель => DTO => json/protobuf/sql/...
⁃ json/protobuf/sql/... => DTO => Модель

Нафига? Почему не сразу преобразовывать из, допустим, json в нашу модель или наоборот? Тем более во всех экосистемах есть механизмы, которые позволяют упаковывать любые объекты, задавая правила преобразования через метаданные, аннотации или еще как-то. Пример из Java:

@Entity
public class User {
    @Id
    private Long id;
    @JsonIgnore              // приходится скрывать
    private String passwordHash;
    @JsonProperty("created_at")
    private LocalDateTime createdAt;

    // getters/setters ...
}

var json = new ObjectMapper().writeValueAsString(dto);

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

Одна и та же сущность для внешнего мира редко представляется одним способом. В зависимости от задачи, это может быть один набор полей или другой. Как это разрулить? Дальше, здесь плохо контролируется процесс, легко может быть такое, что новое поле автоматически попало наружу, хотя вы этого не планировали, но забыли его исключить. А если нужны вычисляемые поля или другое представление (всегда в датах)? В такой ситуации модель будет наполняться доп свойствами и методами, которые готовят доп данные для преобразования, что ведет к сильному загрязнению кода. Что из этого относится к бизнес-части, а что к представлению? Проблема.

DTO позволяют отделить представление от модели в коде, создавая по сути промежуточный слой. Имея его, вы можете независимо развивать свою модель и API для взаимодействия с ним. И да, это один из аспектов MVC, конкретно Model-View.

Готовые DTO гораздо легче чем модели конвертировать в типы на TS если у вас есть такая потребность. Например мы наши DTO (используем Alba), превращаем в типы TS с помощью готового инструмента (Typelizer). С моделями так легко не получится.

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

Но это только базовая история. Если мы еще подключаем инструменты генерации из sql (как в go) или openapi как везде, то те самые DTO создаются вообще автоматически на основе описаний.

Пример для sqlc.Библиотека на базе этого запроса и схемы базы генерирует DTO. Запрос:

INSERT INTO links (original_url, short_name)
VALUES (sqlc.arg(original_url), sqlc.arg(short_name))
RETURNING *;

DTO:

type CreateLinkParams struct {
 OriginalUrl string `json:"original_url"`
 ShortName   string `json:"short_name"`
}

Причем для update будет создана своя структура:

type UpdateLinkParams struct {
 OriginalUrl string `json:"original_url"`
 ShortName   string `json:"short_name"`
 ID          int64  `json:"id"`
}

Здесь отличается только id, но в реальных кейсах, отличий в создании или обновлении одной сущности обычно значительно больше, поэтому количество DTO тут становится еще больше.

DTO, кстати, должны быть имутабельны, иначе туда потечет логика

p.s. Вы сами пишите DTO или генерируете?

Ссылки: Телеграм | Youtube | VK

Ура, новый выпуск уже на канале. В этот раз парный лайвкодинг Vim версус Idea https://youtu.be/YST1h-MAAto?si=B2_Pf0zfCtC3s7V-