Как писать функционал приложения не имея тестов?

Разработка без тестов: правда и последствия

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

Когда приходится писать без тестов

1. Быстрый прототип

Нужно быстро验证 идею, показать концепт:

// Прототип - можно без тестов
function PrototypeComponent() {
  const [count, setCount] = useState(0);
  
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>
    </div>
  );
}

// Но потом нужно переписать с тестами

2. Deadline очень близко

Иногда реальный мир требует компромиссов:

// Временное решение
function QuickFix() {
  // TODO: переписать с тестами
  return <div>...</div>;
}

3. Экспериментальные ветки

При исследовании новых технологий:

git checkout -b experiment/new-library
# Можно писать без тестов для быстрого прототипирования

Почему это плохая идея

1. Невидимые ошибки

// Без тестов этот баг обнаружится в production
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price); // забыл инициализатор
  // Вернёт NaN!
}

2. Усложняет рефакторинг

// Боюсь менять код - вдруг сломаю что-нибудь
function processData(data) {
  let result = [];
  for (let i = 0; i < data.length; i++) {
    result.push({
      id: data[i].id,
      name: data[i].name,
      email: data[i].email
      // ... много другого
    });
  }
  return result;
}

// Хочу упростить, но без тестов не рискну

3. Техдолг растёт экспоненциально

// Месяц без тестов
// Сложно добавлять новый код
// Сложно исправлять баги
// Медленно развивается
// 3 месяца спустя: ночные дежурства, аварийные патчи

4. Новым разработчикам сложно

// Как использовать эту функцию?
function processUserData(data, options) {
  // Без тестов невозможно понять что нужно передавать
}

Как писать функционал, когда нет времени на тесты

1. Минимум - интеграционные тесты

// Не можешь писать unit тесты - напиши хотя бы интеграционные
test('user can login and see dashboard', async ({ page }) => {
  await page.goto('http://localhost:3000/login');
  await page.fill('input[name="email"]', 'test@test.com');
  await page.fill('input[name="password"]', 'password');
  await page.click('button[type="submit"]');
  await page.waitForURL('/dashboard');
  expect(page.url()).toContain('/dashboard');
});

2. Smoke тесты

Проверь что основные пути работают:

test('app loads without errors', async ({ page }) => {
  await page.goto('/');
  const heading = page.getByRole('heading', { name: /Welcome/i });
  await expect(heading).toBeVisible();
});

3. Manual testing чеклист

## Перед отправкой
- [ ] Зарегистрировался новый пользователь
- [ ] Залогинился существующий пользователь
- [ ] Создал новую сущность
- [ ] Отредактировал сущность
- [ ] Удалил сущность
- [ ] Проверил на мобильном
- [ ] Нет console errors

4. Code review вместо тестов

// Один разработчик пишет без тестов
// Второй тщательно review-ит код
// Обсуждают edge cases
function complexAlgorithm(data) {
  // Reviewer должен найти баги
}

Реальный выход: быстрые тесты

Не нужны сложные тесты. Пиши простые и быстрые:

// Хороший быстрый тест - 30 секунд на написание
test('sum calculates correctly', () => {
  expect(calculateTotal([{ price: 10 }, { price: 20 }])).toBe(30);
});

// Плохой медленный тест - 30 минут с mocks
test('... очень сложный', async () => {
  // 100+ строк кода
});

Компромисс: покрытие 70% вместо 100%

// Тестируй только:
// ✅ Бизнес-логику (calculations, validation)
// ✅ API интеграцию
// ✅ Критичные пути (auth, payment, data)
// ✅ Edge cases

// Не тестируй:
// ❌ UI rendering (Testing Library это делает)
// ❌ CSS классы
// ❌ Простые пропсы
// ❌ Копипасту

Мой реальный совет

// Сценарий 1: Спешка + важный код
// Потрать час на базовые тесты
test('auth works', async () => {
  const result = await login('user@test.com', 'pass');
  expect(result.token).toBeDefined();
});

// Сценарий 2: Прототип
// Напиши быстро без тестов
// Но добавь коммент для будущего
function ProtoComponent() {
  // TODO: добавить тесты перед production
  return <div>Prototype</div>;
}

// Сценарий 3: Спешка + простой код
// Просто напиши код + типизацию TypeScript
const formatDate = (date: Date): string => {
  return date.toLocaleDateString('ru-RU');
};

// TypeScript часто заменяет unit тесты

Инструменты для быстрого тестирования

# Быстрые unit тесты
npm test -- --run

# Покрытие только измени файлов
npm run test:coverage -- --only-changed

# Smoke тесты
npm run test:smoke

Заключение

Лучшая стратегия:

1. Идеально: Пиши тесты с кодом (TDD)
2. Спешка: Напиши smoke/интеграционные тесты
3. Прототип: Пиши без тестов, но добавь их потом
4. Никогда: Не удаляй старые тесты
5. Всегда: Используй TypeScript вместо тестов

Код без тестов - это технический долг, который нужно погашать. Лучше потратить 1 час на тесты сейчас, чем 10 часов на дебаг в production.