Введение

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

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

Любая инициатива сопровождается вопросом - зачем?

Вопрос «зачем?» часто скрывает другие проблемы и боли разработчиков. Давайте рассмотрим, почему тесты реально не пишут, и как наш подход помог преодолеть эти барьеры.

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

2. Непонятно, что тестировать и как оценить результат. Отсутствие чёткого понимания, что именно стоит покрывать тестами (вёрстку или бизнес-логику?), и как измерить их реальную пользу. Голые цифры процента покрытия не дают ощущения ценности.

3. Невидимая работа без признания. Тесты — это работа «под капотом». Она требует времени, но редко приносит аплодисменты и видимый результат, в отличие от новой фичи, что снижает мотивацию.

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

Основная концепция: сместить фокус с написания на ревью.

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

Такой подход устраняет главный барьер — страх начать. Мы исходим из принципа: «Лучше работающий, но несовершенный тест сегодня, чем идеальный, но так и не написанный тест завтра». Главное — получить первую рабочую версию, которую затем можно итеративно улучшать, доводя до идеала.

Особенности нашего проекта.

Наша команда работает на Vue (3 и старых костылях от Vue 2: Options API, mixins и тд), Vite, Quasar и Vitest. Мы развиваем внутренний интерфейс, насыщенный сложными бизнес-правилами: динамические формы, фичи, включающие/выключающие части страниц, подтягивание клиентских данных из разных ресурсов и детальные проверки доступов. 

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

Практика внедрения: два трека к успеху.

Наш подход состоит из двух параллельных треков: технического (для разработчика) и организационного (для тимлида). Успех достигается только тогда, когда они движутся синхронно. Технические шаги без поддержки со стороны процессов быстро заглохнут, а организационные требования без простых технических инструментов вызовут отторжение.

Трек 1: Инструкция для разработчика - от настройки до готового теста

Этот трек превращает написание тестов из сложной задачи в простой и повторяемый алгоритм. Ключевая мысль: тесты пишет ИИ, а я выступаю в роли ревьюера.
Давайте рассмотрим пошаговый алгоритм, который изменил отношение нашей команды к тестированию:

Шаг 1. Настраиваем окружение с помощью ИИ.

Первый барьер - «магия конфигов». Делегируем эту задачу ИИ. Даем ему наш package.json и просим подготовить все для тестов.

Пример package.json (Vue 3 + Vite):

{
  "dependencies": {
    "@quasar/extras": "^1.0.0",
    "@quasar/quasar-app-extension-qpdfviewer": "^1.0.0-beta.9",
    "@vue/test-utils": "^2.3.2",
    "axios": "^1.12.0",
    "quasar": "^2.6.0",
    "vue": "^3.3.13",
    "vue-i18n": "^9.3.0-beta.19",
    "vue-router": "^4.0.0",
    "vuex": "^4.0.1",
  },
  "devDependencies": {
    "@babel/preset-typescript": "^7.21.4",
    "@intlify/vite-plugin-vue-i18n": "^3.3.1",
    "@quasar/app-vite": "^1.0.0",
    "typescript": "5.1.6",
  },
  "engines": {
    "node": "^18",
    "npm": ">= 6.13.4"
  }
}

Промт для ИИ: «Вот мой package.json. Настрой, тестовое окружение на Vitest для Vue3. Подготовь список npm-зависимостей (vitest, jsdom, @vue/test-utils@1), команду для установки, конфиг для vite.config.js и скрипты для package.json (test:unit, test:coverage).»

В ответ мы получаем готовую инструкцию, которую остается только выполнить, не вникая в детали документации.

Необходимые библиотеки:

  npm install -D vitest jsdom @vue/test-utils @vitest/coverage-v8

Блок в package.json:

"scripts": {
  "test": "vitest --environment happy-dom",
  "coverage": "vitest run --coverage  --environment happy-dom"
}

Блок в vite.config.js:

test: {
    globals: true,
    setupFiles: ['./tests/unit/setupTests.ts'], //о нем далее
    environment: 'happy-dom',
    coverage: {
      reporter: ['html', 'lcov'],
      exclude: [
        '**/extras/pdf**' 
      ]
    }
  }

Шаг 2. Генерируем первый тест с помощью ИИ.

Барьер «чистого листа» - самый сильный. Вместо того чтобы думать, с чего начать, мы даем ИИ код компонента и просим написать тест.

Промт для ИИ: «Напиши unit-тесты для этого Vue 3 компонента на Vitest, используя Vue Test Utils. Вот код UserProfile.vue. Протестируй computed-свойство greeting, метод loadUserData (замокай API) и условный рендеринг для админа. Используй структуру ААА. Вот код компонента UserProfile.vue: »

<template>
  <div>
    <h1>{{ greeting }}</h1>
    <p v-if="user.isAdmin">Доступ: Администратор</p>
    <button @click="loadUserData">Загрузить данные</button>
  </div>
</template>
<script>
import { api } from '@/api';
export default {
  props: { userId: { type: Number, required: true } },
  data() { return { user: null }; },
  computed: {
    greeting() {
      if (!this.user) return 'Привет, Гость!';
      return `Привет, ${this.user.name}!`;
    },
  },
  methods: {
    async loadUserData() {
      try {
        this.user = await api.fetchUser(this.userId);
      } catch (e) {
        this.user = { name: 'Error', isAdmin: false };
      }},
  },
};
</script>

В результате мы получаем 90% готового файла *.spec.js, что убирает главный ступор - «Я не знаю, как использовать эту библиотеку».

Шаг 3. Запускаем и исправляем.

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

import { describe, it, expect, vi } from 'vitest';
import { mount } from '@vue/test-utils';
import UserProfile from './UserProfile.vue'; //исправляем импорт
import { api } from '@/api';

// Мокаем (имитируем) модуль API, чтобы контролировать его поведение в тестах
// Это позволяет нам не делать реальные сетевые запросы
vi.mock('@/api', () => ({ //этот мок можно вынести в файл setupTests.ts'
  api: {
    fetchUser: vi.fn(),
  },
}));
describe('UserProfile.vue', () => {
  it('должен отображать приветствие для гостя, если данные пользователя не загружены', () => {
    // Arrange (Подготовка)
    const wrapper = mount(UserProfile, {
      props: { userId: 1 },
    });
    // Act (Действие)
    const greetingText = wrapper.find('h1').text();
    // Assert (Проверка)
    expect(greetingText).toBe('Привет, Гость!');
    expect(wrapper.find('p').exists()).toBe(false); // Сообщение для администратора не должно отображаться
  });
  it('должен загружать данные пользователя и отображать приветствие для него', async () => {
    // Arrange (Подготовка)
    const mockUser = { name: 'Иван', isAdmin: false };
    // Настраиваем мок-функцию, чтобы она возвращала тестового пользователя
    api.fetchUser.mockResolvedValue(mockUser);    
    const wrapper = mount(UserProfile, {
      props: { userId: 2 },
    });
    // Act (Действие)
    await wrapper.find('button').trigger('click'); // Кликаем на кнопку для загрузки данных    
    // Assert (Проверка)
    expect(api.fetchUser).toHaveBeenCalledWith(2); // Проверяем, что API был вызван с правильным userId
    expect(wrapper.find('h1').text()).toBe('Привет, Иван!');
  });
  it('должен отображать сообщение для администратора, если у пользователя есть права', async () => {
    // Arrange (Подготовка)
    const mockAdmin = { name: 'Анна', isAdmin: true };
    api.fetchUser.mockResolvedValue(mockAdmin);    
    const wrapper = mount(UserProfile, {
      props: { userId: 3 },
    });
    // Act (Действие)
    await wrapper.find('button').trigger('click');
    // Assert (Проверка)
    const adminMessage = wrapper.find('p');
    expect(adminMessage.exists()).toBe(true); // Проверяем, что элемент <p> существует
    expect(adminMessage.text()).toBe('Доступ: Администратор'); // Проверяем его текст
  });
  it('не должен отображать сообщение для администратора, если у пользователя нет прав', async () => {
    // Arrange (Подготовка)
    const mockUser = { name: 'Петр', isAdmin: false };
    api.fetchUser.mockResolvedValue(mockUser);    
    const wrapper = mount(UserProfile, {
      props: { userId: 4 },
    });
    // Act (Действие)
    await wrapper.find('button').trigger('click');
    // Assert (Проверка)
    expect(wrapper.find('p').exists()).toBe(false); // Элемент <p> не должен существовать
  });
});

Шаг 4. Приводим к стандарту с помощью ИИ.

Первые тесты часто бывают хаотичными. Чтобы поддерживать порядок, мы используем ИИ для рефакторинга.
Промт для ИИ: «Отрефактори этот тест по нашим правилам: структура ААА с комментариями // Arrange, // Act, // Assert; используй beforeEach для создания чистого состояния; названия тестов должны следовать шаблону should [result] when [condition].»

Это учит новичков правильной структуре не через чтение документации, а на практике. Этот цикл «ИИ сгенерировал → вставили → запустили → отрефакторили» и есть основа всего подхода. Он снижает порог вхождения и превращает написание тестов в простую привычку.

Трек 2: Инструкция для тимлида - от инициативы до культуры.

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

Шаг 1. Делаем работу видимой: «публичные победы».

Тесты - «невидимая работа». Ваша задача - сделать ее видимой.
Что делать: На дейли, ретро и демо просите разработчиков упоминать статус тестов: «задача готова, пишу тесты», «тесты для компонента X написаны». Это вводит написание тестов в общее информационное поле и придает ему легитимности.

Шаг 2. Интегрируем в CI/CD: «эффект светофора»

Подключите запуск тестов в пайплайн.
Что делать: На первом этапе не блокируйте Merge Request, если тесты упали. Главное - сделать результат видимым. Зеленая галочка от CI становится символом качества и стабильности, а красная - сигналом, который нельзя игнорировать.

Шаг 3. Включаем в цели и техдолг: создаем мотивацию.

Сделайте написание тестов частью рабочих целей.
Что делать: Включите метрики покрытия или просто количество написанных тестов в квартальные/годовые цели разработчиков. Задача «покрыть тестами старый модуль X» становится привлекательным способом легко закрыть часть техдолга и личных KPI.

Шаг 4. Фиксируем результат: набираем критическую массу.

Когда покрытие достигло значимого уровня (у нас это было 50%, цифра может быть любой, главное предотвратить стагнацию), закрепите успех.
Что делать: Настройте Quality Gates в SonarQube или аналогах. Установите правило: «Покрытие нового кода не должно быть ниже n%». Это предотвратит откат назад и закрепит новую норму.

Шаг 5. Внедряем политику по упавшим тестам: «не храним мертвечину»

Упавшие тесты, которые никто не чинит, демотивируют и создают шум.
Что делать: Внедрите простое правило: «Если тест упал и его сложно починить за 15-20 минут - удаляйте его». Лучше потом написать новый, актуальный тест, чем тратить часы на отладку устаревшего. Это сохраняет тестовую базу чистой и полезной.

Что стало лучше: Результаты внедрения.

Мы не просто получили красивую цифру в SonarQube. Мы добились конкретных улучшений:

• Уверенность в рефакторинге: раньше изменение общей функции было минным полем. Сейчас, если после правок тесты зеленые, мы на 80% уверены, что ничего не сломали.

• Подтвержденная устойчивость при архитектурных изменениях: в процессе перехода от монолита к микросервисам мы смогли перенести существующие тесты для каждого выделяемого сервиса без единого изменения. Это стало ключевым фактором, который подтвердил надежность нашего тестового покрытия и дал команде бесценную уверенность в правильности выбранного пути. Ускорение онбординга: новички быстрее понимают, как работает компонент, читая его тесты - живую документацию его поведения.

• Упрощение код-ревью: ревьюер видит, что компонент покрыт тестами, и может сфокусироваться на архитектуре и стиле кода.

Ответ на главный вопрос: Так почему никто не любит писать тесты?

Так удалось ли нам исправить нелюбовь к тестам? Частично. Мы не заставили команду полюбить их. Любовь - чувство иррациональное. Вместо этого мы устранили ключевые барьеры, которые эту нелюбовь вызывали:

• Страх и неизвестность («Я не знаком с этой библиотекой», «что тестировать») - убрали с помощью ИИ, который дает готовую точку старта.

• Ощущение бесполезной траты времени («фича нужна вчера», «работа, которую не видят») - убрали, сделав процесс быстрым, а результат видимым.

• Высокий порог входа («конфиги, моки») - снизили, начав с простейших тестов.

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

Заключение

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

Наша статистика и итоги:

Безусловно, успех проекта зависит не только от юнит-тестов. Значительный вклад вносят также архитектурные решения, такие как переход на микросервисы, интеграция инструментов контроля качества вроде SonarQube, а также оптимизация процессов разработки, например, усовершенствование Git-flow. Однако недооценивать очевидную пользу от тестирования было бы ошибкой.