Что такое «модульное тестирование»?

Модульное/компонентное тестирование (unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.

Модульные тесты можно условно поделить на две группы:
• тесты состояния (state based), проверяющие что вызываемый метод объекта отработал корректно, проверяя состояние тестируемого объекта после вызова метода.

• тесты взаимодействия (interaction tests), в которых тестируемый объект производит манипуляции с другими объектами. Применяются, когда требуется удостовериться, что тестируемый объект корректно взаимодействует с другими объектами.

Чем stub отличается от mock?

stub используется как заглушка сервисов, методов, классов и т.д. с заранее запрограммированным ответом на вызовы.

mock использует подмену результатов вызова, проверяет сам факт взаимодействия, протоколирует и контролирует его.

​👨‍💻👩‍💻ТОП-15 корисних посилань для самопідготовки в ІТ

Скоро ми переможемо і на Україну чекає хвиля змін, інноваційний прорив та економічне зростання. Нашій країні знадобиться ще більше кваліфікованих ІТ-фахівців, які зможуть підкорити цю хвилю своєю майстерністю та технічними рішеннями. Саме тому наша рекомендація дуже проста: якщо ви та близькі в безпеці та маєте можливість подумати про майбутнє – починайте готуватись до нього вже зараз!

Ми підготували перелік корисних посилань для ІТ-початківців, які тільки починають свій професійний шлях або тих, хто планує змінити свою теперішню кар’єру.

1) ENGLISH🔥 English Self-Study Materials | Безліч корисних матеріалів за всіма рівнями, що підійдуть для кожного.

2) BASICS🔥 Harvard course CS50 - курс CS50 Гарвардського університету вважається найкращим з основ програмування в світі. Він розрахований як на повних новачків, так і на більш досвідчених в програмуванні. Програма включає лекції та практичні завдання.

3) FRONTEND🔥 Codecademy HTML & CSS - зрозуміти, як працює HTML и CSS – першочергова задача всіх, хто хоче почати вивчення будь-якої професії в ІТ. А в CodeAcademy є досить багато онлайн курсів за усіма напрямками в ІТ.
+ W3SCHOOLS – англомовний ресурс для самостійного вивчення FrontEnd, тут завжди найновіша та найбільш актуальна інформація.

4) JAVA🔥 The Java™ Tutorials – оригінальна документація компанії Oracle з мови Java. Основа основ та першоджерело усіх знань з Java.
+ Корисна стаття на нашому порталі: «З чого почати?» Які знання необхідні розробнику-початківцю.

5) .NET🔥 Офіційна документація Microsoft з мови C# - тут є багато ресурсів для вивчення мови C#. Залежно від вашого досвіду програмування чи роботи з мовою C# та платформою .NET, вам будуть цікаві різні розділи цього посібника.
+підбірка Bookshelf початківця в .NET-розробці.

6) SOFTWARE TESTING🔥 Книга International Software Test Institute – ця книга охоплює всі аспекти тестування програмного забезпечення, розповідаючи про всі процеси, метрики та ризики в тестуванні.
+стаття Що читати та дивитися тестувальнику-початківцю.

7) DEVOPS🔥Матеріали для самопідготовки та безліч корисних матеріалів від EPAM University.

8 ) BUSINESS ANALYSIS🔥 Для чого потрібен бізнес-аналіз і хто такі бізнес-аналітики?
+стаття Що роблять бізнес-аналітики в ІТ, необхідні знання та вміння

9) BUSINESS INTELLIGENCE🔥 SQL Tutorial - для початківців та не тільки. Знадобиться в роботі ВІ не одну сотню разів.

10) 🔗А також, дуже рекомендуємо зберегти собі розділ з матеріалами на нашому EPAM Training Portal, де ми зібрали безліч корисних статей та додаткових важливих посилань.

💙💛Все буде Україна!

Разбор 4х задач по SQL, которые могут встретиться на собеседовании.

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

🔗 Часть 1
🔗 Часть 2
🔗 Часть 3

Идемпотентность

Идемпотентная операция — операция, которая при многократном вызове оставляет систему в одном и том же состоянии. Это значит, что:
🔸 Возвращаемый результат один и тот же
🔸 Сайд эффекты не накапливаются

Неважно сколько раз вызван метод — эффект будет одинаковый. Что может быть сайд-эффектом: запись в БД, обновление статистики, запись в файл, изменение общих переменных.

Примеры идемпотентных операций:

✅ Удалить элемент с id=50
(10 вызовов → 1 удаление)
❌ Удалить элемент максимального размера
(10 вызовов → 10 удалённых элементов)
✅ Прочитать число из БД, умножить результат на 2 и вернуть пользователю
❌ Прочитать число из БД и обновить статистику запросов

В чём смысл?

Идемпотентные операции повышают устойчивость системы.

Допустим, мы отправили запрос на сервер, и соединение пропало. Спустя 3 секунды восстановилось. Возникает дилемма:

🤔 Отправить запрос ещё раз? Но вдруг он уже был обработан…
🤔 Может не отправлять? А если предыдущий пропал…

Запрос либо дублируется, либо теряется. Для идемпотентного запроса такой проблемы нет, можно спокойно отправить его ещё раз.

На собеседованиях вопрос идемпотентности обычно обсуждают со стороны HTTP вызовов. Нужно сказать, что GET, PUT and DELETE идемпотентные, а POST — нет.

Но жизнь чуть сложнее.

🔹 Во-первых, идемпотентность зависит от бизнес-логики, а не от выбранного метода

Здесь самое сложное — держать под контролем сайд эффекты. Возьмём как пример увеличение счётчика в БД:

UPDATE t SET value=value+1

Как сделать его идемпотентным?

Добавить в таблицу (и сущность) поле version. Клиент передаёт номер текущей версии при обновлении. Запрос получается такой:

UPDATE t SET value=value+1, version=version+1 WHERE version=88

🔹 Во-вторых, POST запросы можно сделать идемпотентными. Например так:

Клиент генерирует ID и добавляет его в хэдер HTTP запроса:

Idempotency-Key: 4872934

Сервис хранит у себя список ID недавних запросов. Если операции с таким ID ещё не было, сервис начнет выполнение.

Процесс фильтрации дубликатов называется дедупликацией.

❓ Выглядит как лишняя сложность, нужна ли вообще идемпотентность?

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

​Message brokers, часть 1: RabbitMQ

Оба брокера реализуют паттерн publish/subscribe. Его основные участники это

🔸 Producer — отправляет сообщения. Сообщение состоит из ключа, значения и хэдеров
🔸 Consumer — принимает сообщения
🔸 Message broker — компонент для обмена сообщениями, разворачивается отдельно

Основная структура данных для распределения сообщений — очередь. Обычно в системе целое море продюсеров, очередей и консьюмеров. Чтобы упростить общение между ними, RabbitMQ использует промежуточный слой — exchangers.

Принцип работы:

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

Консьюмер подсоединяется к интересным очередям и забирает оттуда сообщения.

Чтобы было понятно, как это выглядит, посмотрите на картинку внизу поста👇

Сообщение удаляется из очереди после прочтения. Отсюда идут следующие схемы:

▫️ Если сообщение должны прочитать несколько получателей — у каждого должна быть своя очередь, куда это сообщение попадёт.

Пример: сообщение order.from-A.to-C. vip попадает в две очереди — order.from-A.* и order.*.*.vip

▫️ Если нужно распределить сообщения между получателями, консьюмеры подключаются к одной очереди. RabbitMQ распределяет сообщения между ними равномерно по принципу round-robin.

Пример: сообщение order.from-A.to-B и order.from-A.to-C распределяются между консюмерами С1 и С2

Рэббит использует push модель — каждое сообщение из очереди вызывает коллбэк на консьюмере. Это нужно, чтобы равномерно распределять сообщения между получателями.

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

Главное в RabbitMQ:
✔️ Основной компонент — exchanger и связанные с ним очереди
✔️ Сообщения удаляются после прочтения
✔️ Push-модель
✔️ Гибкий роутинг сообщений

​Message brokers, часть 2: Kafka

Если RabbitMQ — это 100% очередь, то Kafka больше похожа на список, потому что данные после чтения не удаляются. В принципе это основное отличие двух брокеров, остальное — просто следствие.

Один список называется partition. Несколько partition можно объединить в группу, которая называется topic.

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

Если в partition 10 сообщений, то
🧔🏻 Один консьюмер прочитает сразу всё
👳🏻 Другой прочитает 5 и потом ещё 5
👩🏼‍🦰 Третий будет вычитывать по одному сообщению

И никто никому не мешает☺️

В рамках одного partition все консюмеры читают сообщения в одном порядке. Иногда это очень важная фича. Для топика из нескольких partition такой гарантии нет.

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

🔸 Если сообщение должны прочитать несколько однотипных получателей, достаточно записать их в один partition

🔸 Если получатели разнотипные, то продюсер должен добавить данные в несколько партишенов.
Пример: чтобы сообщение “A to C vip” прочитали C1 и C4, продюсер отправляет запись в топик orders и vip_orders.

🔸 Если нужно распределить сообщения по получателям, то консьюмеры объединяются в consumer group с общим оффсетом

Резюме

▫️ В Kafka сообщения не пропадают при чтении, их можно читать несколько раз и пачками
▫️ Гарантия порядка сообщений в рамках одного partition
▫️ Kafka занимает горааааздо больше места на диске
▫️ Kafka использует pull модель — получатели сами решают, когда забрать сообщения. В RabbitMQ инициатива исходит от очереди, чтобы равномерно распределять сообщения
▫️ Разные схемы общения с продюсерами и консьюмерами. На картинке ниже я представила аналог схемы из предыдущего поста
▫️ Разные сценарии масштабирования и отказоустойчивости
▫️ Субъективное мнение — в рэббите проще распределять сообщения по получателям. Kafka подходит для накопления данных и более сложных сценариев
▫️Объективное — Kafka используется на бОльшем количестве проектов, пусть даже в качестве простой очереди😐

Общие черты двух брокеров:

🐰🐞 Отлично поддерживаются спрингом
🐰🐞 Можно настроить хранение сообщений на диске
🐰🐞 Нужно супер тщательно продумать схему работы и масштабирование

PS Эти посты — самые основы месседж брокеров, прямо вот верхушечка. Для дальнейшего изучения подойдёт эта серия статей, книги "RabbitMQ in Action" и "Kafka in Action".

Transient = do not serialize the field

DevOps (або Development & Operations) - відносно нова позиція в ІТ, пов'язана із вирішенням питань інфраструктури, інтеграції й оптимізації процесу завантаження й оновлення релізів продукту.

📈 Попит на DevOps-ів у світі стрімко зростає. Спеціалістам цього напрямку зі старту пропонують високі зарплати у валюті, проте й працювати доводиться із широким спектром технологій.

Якщо DevOps для тебе - не дивний акронім, а один із пріоритетних напрямків кар'єрного розвитку, наша сьогоднішня добірка корисностей саме для тебе 🤟🏻

📌 Актуальні статті для новачків у DevOps:
- Мануал для джуна. Що треба знати початківцю в DevOps: 30 запитань і поради досвідченого ліда
- Тренди DevOps — що треба знати і вміти інженеру в 2022 році
- Співбесіда з DevOps. 300+ запитань для Junior, Middle, Senior

📌 Безкоштовна сертифікація від SoftServe Academy

Навіть під час війни майже щомісяця запускаються нові стажування за напрямком DevOps від великих IT-компаній. Тож залишайся з нами та не пропусти саме свою кар'єрну можливість 🙃

🐲 Пам'ятка: часова складність структур даних

В минулих дописах рубрики #алгоритми ми дізналися, що вирішення кожної задачі потребує окремої структури даних для оптимізації ресурсів — а ще раніше з'ясували, що таке складність (О-нотація) алгоритмів.

Сподіваємось, ще не все встигло вилетіти з пам'яті 🌝

👉 Зібрали в одну картинку складності чотирьох найпростіших операцій з даними для найпоширеніших структур.

HashMap и принципы SOLID

На большинстве собесов спрашивают одно и то же. Как работает HashMap, принципы ООП и SOLID, разница абстрактного класса и интерфейса, жизненный цикл бина.

Когда я была junior/middle, 80% вопросов повторялись на каждом собеседовании. И вопросы возникали уже у меня:
🤔 Как интервьюеры поймут, что я топчик, если спрашивают такую банальщину?
🤔 Почему в вакансии целая страница требований и технологий, но мы ничего из этого не обсуждаем?
🤔 Может на проекте всё очень плохо, а код написан на java 6?

И только когда я начала собеседовать людей, то поняла, зачем это всё.

Всё дело в специфике найма джуниоров и мидлов.

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

Поэтому важно, чтобы человек имел крепкий фундамент и был приятным в общении на технические темы. И стандартные вопросы подходят для этого великолепно:

1️⃣ Это база🤌

Желание обсудить саги и агрегаты это здорово, но большую часть времени разработчик проводит с кодом. Stream API, коммиты, структуры данных — в этом не должно быть пробелов.

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

Сегодня собесы больше ориентируются на практику. Бывает, что кандидат лихо объясняет synchronization order, но не видит ошибок в простом многопоточном коде. Не смущайтесь лёгких заданий, они не так просты, как кажутся:)

Время собеседования очень ограничено. Выделенные 30-60 минут лучше потратить на базу. Если с ней всё хорошо — остальное приложится

2️⃣ Легко сравнить кандидатов между собой

Если 10 человек расскажут устройство HashMap, получится 10 разных ответов.

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

Поэтому часто стандартных вопросов достаточно, чтобы понять, насколько приятно общаться с человеком и как глубоко он понимает базу. Умничку видно сразу🙂

❓ Если спрашивают банальщину — значит проект скучный?

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

❓ Как выделиться среди других кандидатов, если задают только общие вопросы?

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

Если интервьюер чем-то заинтересуется в вашем опыте, он обязательно спросит:)

❗️ Я отвечал на всё правильно, но оффер не прислали!

Причина может быть вообще не в вас. Может пришёл кандидат с более релевантным опытом, или бюджет перераспределили на другие цели.

Найм — очень субъективный процесс. Интервьюер всегда найдёт, к чему прицепится, если у вас фамилия, как у его бывшей жены. И наоборот, если с первых минут установился контакт, даже небольшие ошибки не испортят впечатления.