Оголошення

Як Ми Створили 273 Юніт-Тести за 3 Дні, Не Написавши Жодного Рядка Коду

Як Ми Створили 273 Юніт-Тести за 3 Дні, Не Написавши Жодного Рядка Коду

Цей пост є Частиною 3 з серії з 4 частин. Обов’язково переглянь інші пости в серії, щоб глибше зануритися в наш генератор бізнес-планів на базі ШІ.
Частина 1: Як ми створили генератор бізнес-планів на базі ШІ за допомогою LangGraph & LangChain
Частина 2: Як ми оптимізували генерацію бізнес-планів на базі ШІ: швидкість проти якості компромісів
Частина 3: Як ми створили 273 модульних тестів за 3 дні без написання жодного рядка коду
Частина 4: ШІ Оціночна Схема — Як ми створили систему для оцінки та поліпшення бізнес-планів, створених ШІ

У швидко змінюваному ландшафті розробки програмного забезпечення роль штучного інтелекту розширюється за межі генерації коду до автоматизації тестування. Протягом інтенсивного триденного періоду у лютому 2025 року ми провели глибоке дослідження в DreamHost, оцінюючи, наскільки ефективно ШІ може самостійно писати модульні тести з мінімальним втручанням людини. Ця стаття ділиться ключовими результатами, метриками та висновками, які можуть змінити наш підхід до автоматизації тестування.

Дослідницька Преміса

Основна мета була чіткою: оцінити, чи може ШІ надійно створювати тестові модулі виробничої якості без написання коду людьми. Це було не просто академічне завдання — у DreamHost ми застосовуємо ШІ для того, щоб у “100000x” збільшити нашу продуктивність у проєкті Планувальник бізнесу з ШІ, і це дослідження було розроблене для подальшого розширення цих меж. Такий підхід є значним відходом від традиційних робочих процесів модульного тестування і може драматично вплинути на продуктивність розробки.

Параметри Проєкту

Для цього дослідження ми розробили структуровану методологію:

  1. Вхідні дані ШІ: Надай ШІ вихідний код, приклади тестових файлів, що демонструють паттерни/стиль, вимоги до тестування та контекст середовища розробки
  2. Людські обмеження: Обмеж людський внесок до уточнень, виправлень неправильних уявлень та надання відсутнього контексту — без прямого написання коду
  3. Фокус на вимірюванні: Відстежуй час до завершення, необхідні ітерації, типи зустрічених помилок, якість результату, досягнуте покриття та необхідні людські зусилля

Наші критерії успіху були амбітними, але необхідними для застосування у виробництві:

  • 100% охоплення тестами
  • Реалізація з типовою безпекою
  • Дотримання кращих практик тестування
  • Мінімальне втручання людини
  • Розумний час завершення
  • Підтримуваний тестовий код

Ключові Результати Досліджень

За лише три дні наша команда додала 273 нові тести до проекту Планувальника бізнесу, що значно збільшило наше покриття тестами. Після аналізу численних імплементацій тестів, створених ШІ, у різних сервісах та компонентах, було виявлено кілька закономірностей, які надають цінні вказівки щодо поточного стану ШІ-керованого модульного тестування.

1. Метрики Ефективності

Одним з найбільш помітних результатів було значне скорочення часу впровадження:

Зекономлений час значний — більшість тестових імплементацій було завершено менше ніж за 10 хвилин, тоді як еквівалентний час людини становить 30–60 хвилин на ту саму задачу. Це означає потенційне збільшення продуктивності в 4–6 разів для рутинного написання тестів.

2. Сильні Сторони Тестування ШІ

За допомогою багаторазових реалізацій, певні можливості ШІ постійно вирізнялися:

  • Всебічне Покриття: ШІ досягла постійно 96–100% покриття коду в різних складностях сервісів
  • Розпізнавання Зразків: ШІ відмінно справлялася з розпізнаванням тестових зразків з прикладів та їх послідовним застосуванням
  • Адаптація до Зворотного Зв’язку: Більшість помилок могли бути вирішені з мінімальними уточненнями
  • Макетна Реалізація: ШІ продемонструвала сильні здібності у створенні відповідних макетів та тестових приладдів
  • Послідовність Структури: Організація тестування відповідала кращим практикам із чіткими схемами впорядкування-дії-перевірки

3. Спостережені Обмеження Та Виклики

Попри вражаючі результати, з’явилося кілька повторюваних викликів:

  • Опрацювання Типів TypeScript: Найчастішим джерелом помилок було неповне визначення типів або неправильні припущення щодо типів
  • Розуміння Структури Проекту: Шляхи імпорту та відносини залежностей часто вимагали людського коригування
  • Охоплення Крайових Випадків: Хоча основні шляхи були добре покриті, складна умовна логіка іноді потребувала додаткових тестових випадків
  • Припущення Щодо Шаблонів: ШІ іноді робив необґрунтовані припущення щодо специфічних для додатків шаблонів або патернів
  • Вимоги до Ітерацій: Більш складні сервіси вимагали більшої кількості обмінів для досягнення повного охоплення

Моментальні Знімки Кейс-Стадії

Давайте розглянемо кілька репрезентативних реалізацій, щоб краще зрозуміти ці патерни.

Випадок 1: Тестування Простого Експорту Констант

Для тестування файлів, які переважно містять сталі експорти:

  • Час Впровадження: 1 хвилина 30 секунд
  • Тестові Випадки: 10
  • Покриття: 100%
  • Ітерації: 1 (без необхідності виправлень)
  • Підхід: Ефективне використання тестування знімків для великих постійних об’єктів

Цей випадок демонструє, що для простих тестових сценаріїв ШІ може генерувати повністю готові тести без жодних ітерацій — по суті “ідеальні” з першої спроби.

Кейс 2: Складний Сервіс з Залежностями DI

Для більш складної служби з ін’єкцією залежностей:

  • Час впровадження: 4 хвилини 50 секунд
  • Тестові випадки: 5
  • Покриття: 100%
  • Ітерації: 2
  • Виклики: Для впровадження тесту Bootstrap потрібно виправити прив’язки залежностей

ШІ успішно впоралася з тестуванням ін’єкції залежностей, потрібні лише незначні коригування для ініціалізації контейнера.

Випадок 3: Високоскладна Послуга з Багатьма Галузями

Для найбільш складних послуг, що тестуються:

  • Час Реалізації: 24 хвилини
  • Тестові Випадки: 11
  • Покриття: 51.26% (нижче мети)
  • Ітерації: 5–6
  • Виклики: Труднощі з досягненням повного розгалуженого покриття для складної умовної логіки

Це представляє важливий межовий випадок, коли ШІ все ще має труднощі зі всебічним тестуванням дуже складної розгалуженої логіки.

Наслідки для Процесу Розробки

Ці висновки пропонують кілька змін у тому, як ми можемо підійти до реалізації тестів:

1. Оновлений Робочий Процес

Замість того, щоб розробники писали тести з нуля, більш ефективним виявляється наступний процес:

  1. Розробник надає вихідний код та приклади тестів ШІ
  2. ШІ створює початкову реалізацію тесту
  3. Розробник надає ітеративний відгук щодо конкретних питань
  4. ШІ удосконалює реалізацію, поки не будуть досягнуті цілі покриття
  5. Розробник виконує остаточний огляд та здійснює коміти

Цей підхід дозволяє розробникам зосереджуватися на перевірці якості тестів та крайових випадках, а не на написанні шаблонного тестового коду.

2. Можливості Оптимізації

Кілька практик значно покращили продуктивність генерації тестів ШІ:

  • Надання чітких прикладів тестів у тому ж стилі/форматі
  • Визначення точних вимог до покриття заздалегідь
  • Включення інформації про складні типи
  • Проактивне виявлення потенційних крайніх випадків
  • Використання підходів, заснованих на тестуванні, де ШІ має доступ одночасно до реалізації та тестів

3. Економічний Вплив

На основі порівняння часу імплементації ШІ та оціненого часу імплементації людиною, потенційне зростання продуктивності є значним:

  • Зменшення часу, витраченого на написання рутинних модульних тестів на 70–85%
  • Більш висока послідовність покриття
  • Швидші цикли зворотного зв’язку під час розробки
  • Більше тестових випадків за той самий обсяг розробки

Погляд У Майбутнє: Перспективи Тестування, Що Керується ШІ

Це дослідження є раннім розслідуванням того, що, ймовірно, стане стандартною практикою розробки. Кілька тенденцій вказують на те, куди рухається ця галузь:

Майбутні Можливості

  1. Розробка через тестування: ШІ може генерувати тести та код імплементації ітеративно
  2. Інтеграція з CI/CD: Автоматичне генерування тестів та їх підтримка під час процесу збірки
  3. Навчання за спеціалізованим доменом: Точне налаштування моделей для конкретних кодових баз або патернів
  4. Самовідновлювані тести: ШІ, який оновлює тести при зміні імплементації
  5. Спеціалізовані моделі тестування: Моделі ШІ, оптимізовані спеціально для генерації тестів

Залишкові Виклики

Незважаючи на значний прогрес, залишається кілька викликів:

  1. Складне Управління Станом: Тестування компонентів із станом та складними взаємодіями
  2. Спеціалізовані Знання: Тести, які потребують галузевих знань або бізнес-правил
  3. Інтеграційне Тестування: Виходячи за межі модульного тестування до інтеграційних та системних тестів
  4. Тестування Продуктивності: Ідентифікація та написання ефективних тестів продуктивності
  5. Тестування Безпеки: Виявлення та використання вразливостей безпеки

Підсумок Проєкту: Цифри

Ось моментальний знімок того, що ми досягли в нашому триденному експерименті:

  • Тестові Додавання: Додано 273 нових тести (від 22 до 295 загалом)
  • Рівень Успіху: ~90% спроб успішно досягли 100% покриття
  • Час Впровадження: В середньому 5–8 хвилин на компонент
  • Найбільший Набір Тестів: Додано 273 тести приблизно за 6 годин загального робочого часу
  • Найшвидше Впровадження: 90 секунд для знімків фреймворку з 100% покриттям
  • Найскладніший Випадок: Компонент графіка з 13 залежностями, виконаний за 5 хвилин
  • Рівень Якості: Збережена якість коду на рівні старшого розробника
  • Людський Вклад: Нуль рядків коду, написаних людьми

З точки зору ROI, ми оцінюємо економію часу в 70–80% порівняно з ручним впровадженням, без компромісів щодо якості. Єдиною помітною невдачею було використання RunsService, де нам вдалося досягти лише 51% охоплення через надзвичайно складну логіку розгалуження.

Висновок: Практичні Рекомендації

На основі цього дослідження ми рекомендуємо наступні практики для команд, які бажають використовувати ШІ для модульного тестування:

  1. Почати Просто: Почни з простих компонентів, які слідують встановленим шаблонам
  2. Надати Приклади: Включи репрезентативні приклади твого стилю тестування
  3. Ітеративний Зворотній Зв’язок: Плануй 2–3 цикли зворотного зв’язку для досягнення оптимальних результатів
  4. Зосередитися На Крайових Випадках: Використовуй свої знання в галузі, щоб запропонувати крайові випадки, які ШІ може пропустити
  5. Встановити Чіткі Критерії: Визнач, що означає “завершеність” для покриття тестами та стилю
  6. Регулярні Оновлення: Оскільки моделі ШІ вдосконалюються, переглянь свій підхід, щоб використати нові можливості

Найцікавішим аспектом цього дослідження є те, що воно представляє лише початок. Оскільки можливості ШІ продовжують розвиватися, потенціал тестування на базі ШІ буде розширюватися на більш складні сфери тестування, що в кінцевому підсумку трансформує наш підхід до забезпечення якості у розробці програмного забезпечення.

Це дослідження було проведено протягом трьох днів у лютому 2025 року над проектом Бізнес-планувальника DreamHost, за допомогою кількох моделей ШІ, включаючи GitHub Copilot, моделі GPT від OpenAI та Claude від Anthropic. Тестове середовище було сервісом на базі TypeScript з Jest та ts-mockito для тестування, зосередженим на компонентах додатків реального світу. Найважливіше, що ми не написали жодного рядка коду протягом усього процесу — всі дії з тестування здійснювались ШІ з лише людським керівництвом.

Цей допис є Частиною 3 з серії з 4 частин. Обов’язково перегляньте інші дописи серії, щоб глибше зануритись у наш генератор бізнес-планів з ШІ.
Частина 1: Як ми створили генератор бізнес-планів з ШІ, використовуючи LangGraph & LangChain
Частина 2: Як ми оптимізували генерацію бізнес-планів з ШІ: швидкість проти якості
Частина 3: Як ми створили 273 юніт-тести за 3 дні без написання жодного рядка коду
Частина 4: ШІ-фреймворк оцінювання — як ми створили систему для оцінки та вдосконалення бізнес-планів, сгенерованих ШІ