Ответ
Да, в таких командах ответственность за качество продукта полностью ложится на разработчиков. Мы применяли стратегию "разработчик отвечает за тестирование своего кода" и внедряли культуру качества.
Ключевые практики обеспечения качества:
- Модульное тестирование (Unit Testing): Покрытие логики методов с помощью JUnit/TestNG.
@Test @DisplayName("Расчет скидки: 10% от 100 должен дать 90") void calculateDiscount_ShouldReturnCorrectValue() { DiscountService service = new DiscountService(); BigDecimal result = service.calculateDiscount(new BigDecimal("100"), 10); assertEquals(new BigDecimal("90.00"), result); } - Интеграционное тестирование: Проверка взаимодействия компонентов (Spring Boot Test, Testcontainers для БД).
- Автоматизация в CI/CD: Настройка пайплайнов (GitHub Actions, Jenkins) для автоматического запуска всех тестов при каждом push или создании PR. Сборка не проходит, если падают тесты.
- Статический анализ кода: Использование SonarQube, Checkstyle для выявления потенциальных багов и "запахов" кода.
- Взаимное ревью кода (Peer Review): Коллеги проверяют не только логику, но и тестовое покрытие новых функций.
- Приемочное тестирование (Acceptance Testing): Иногда с использованием инструментов вроде Cucumber для проверки сценариев от лица пользователя.
Такой подход формирует shift-left менталитет, где качество закладывается на этапе проектирования и написания кода, а не откладывается на потом.
Ответ 18+ 🔞
А, ну это же классика, блядь! Ты про то, когда за качество продукта отвечает не какой-то там отдельный тестировщик, который потом прибежит с криками «всё сломалось!», а ты сам, сука, и есть и разработчик, и тестировщик, и ответственный за всё, в рот меня чих-пых!
Вот смотри, как у нас это работало, на примере. Представь, ты написал какую-нибудь хрень, которая скидку считает. Ну, казалось бы, ерунда. Но нет, блядь! Ты же не можешь просто так в продакшен это выкатить, а потом охуевать, почему у клиента со ста рублей десять процентов — восемьдесят пять получилось. Поэтому первое, что делаешь — пишешь на эту свою же херню тест.
Вот, смотри, как это выглядит, простейший пример:
@Test
@DisplayName("Расчет скидки: 10% от 100 должен дать 90")
void calculateDiscount_ShouldReturnCorrectValue() {
DiscountService service = new DiscountService();
BigDecimal result = service.calculateDiscount(new BigDecimal("100"), 10);
assertEquals(new BigDecimal("90.00"), result);
}Всё, прикол в чём? Ты написал код, который должен работать. А потом ты пишешь код, который проверяет, работает ли он. И если этот тест падает — значит, ты, мудак, где-то накосячил в основной логике. И пока этот тест не пройдёт зелёным, ты даже не думай коммитить эту дичь. Это как самопроверка, блядь. Написал — тут же сам себя и обосрал, если что не так. Здорово, да?
Но это только начало, ёпта! Потому что твой сервис скидок — он же не в вакууме живёт. Он с базой данных общается, с другими сервисами, с какими-то внешними апишками. И вот тут начинается интеграционное тестирование. Ты поднимаешь настоящую (или почти настоящую) среду — базу в докере через Testcontainers, мокаешь внешние вызовы — и проверяешь, что вся эта конструкция не развалится, как карточный домик, при первом же чихе.
А самое главное — всё это дерьмо должно запускаться автоматически, блядь! Настроили пайплайн в Jenkins или GitHub Actions, и теперь при каждом твоём пуше, при каждом создании пул-реквеста, эта адская машина сама поднимает всё, что нужно, и гоняет все твои тесты. И если хоть один упал — сборка не проходит, и твой код никуда не попадёт. Никаких «ой, я на своей машине проверял, всё работало». Не, сука, не прокатит. Здесь доверия ебать ноль. Только зелёный статус сборки.
Ну и конечно, статический анализ. SonarQube, Checkstyle — эти штуки смотрят на твой код, как хитрая жопа, и говорят: «Э, дружок-пирожок, а у тебя тут потенциальный NullPointerException висит, а тут метод на двести строк, а тут сложность космическая». И ты это всё чинишь, пока не получишь одобрение.
И кульминация всего этого цирка — ревью кода. Ты заливаешь свою фичу, а твои коллеги приходят и начинают её разбирать. И смотрят они не только на саму логику, а в первую очередь, блядь, на тесты! «А где тест на граничное условие? А что будет, если скидка 0%? А если 100%? А если отрицательная?». И ты такой сидишь и понимаешь, что опять облажался, потому что не предусмотрел кейс, когда клиенту надо не скидку дать, а наценку сделать, ёпта!
Вот этот весь подход и называется shift-left. Суть в том, чтобы о качестве думать не в самом конце, когда уже всё почти готово и только баги фиксить, а прямо с самого начала, на этапе проектирования и написания первой строчки кода. Ты с самого старта пишешь так, чтобы потом не было мучительно больно. А иначе — пидары налетят на ревью и разнесут твой код в пух и прах.