Sonarsource спонсировал этот пост. Insight Partners является инвестором в Sonarsource и TNS.
ИИ быстро преобразует разработку программного обеспечения, а помощники по кодированию ИИ в настоящее время являются обычным явлением, предлагая все, от автоматического заполнения до генерации существенных кодовых блоков. Особенно заманчивым применением является автоматическая генерация тестов-единицы, интеграция и сквозной.
Перспектива создания испытаний ИИ, повышения показателей охвата и освобождения разработчиков от часто поддержанной задачи создания тестов звучит как прямой путь к более быстрому обратной связи и завоевание непрерывного кода. Но является ли эта мощная новая возможность надежным активом или обманчивого ярлыка?
Как и любой сложный инструмент, ИИ не является волшебным решением. Некритическое принятие испытаний, сгенерированных AI, может привести к ложному чувству безопасности. Разработчики могут полагать, что их кодовая база надежна из -за высоких испытаний, в то время как сами тесты могут быть поверхностными или даже ошибочными.
Как разработчики могут эффективно использовать ИИ для генерации тестов, пожиная свои преимущества без ущерба для качества кода?
Ученичество ИИ: корни теста ненадежности
Чтобы понять, почему тесты ИИ требуют проверки, очень важно понять, как изучают эти ИИ, генерирующие код. Большинство из них являются крупными языковыми моделями (LLMS), обученными обширным наборам данных — миллиарды строк кода из общественных репозиторий, таких как GitHub, такие платформы, как переполнение стека, проекты с открытым исходным кодом и, возможно, код вашей собственной компании.
Благодаря этому масштабному приемому употреблению ИИ изучает паттерны: общие структуры кодирования, типичное использование API, популярные библиотеки и распространенные стили кодирования. Он становится искусным в прогнозировании следующей последовательности кода, что позволяет ему писать код, который часто кажется правильным на поверхности.
Врученная ловушка заключается в характере этих учебных данных. Это неизбирательная коллекция всех типов кода (например, код, который пронизан ошибками или кодом, который содержит уязвимости безопасности).
ИИ по своей сути не отличает «хорошего» кода от «плохого» кода; Это просто воспроизводит закономерности, которые он наблюдал чаще всего. Если в его тренировочном наборе часто бывают багги, это будет воспроизводить их. Это классическая дилемма «мусор, мусор». Следовательно, когда разработчики задают AI с помощью письменных тестов, может возникнуть несколько критических вопросов.
Минное поле: общие недостатки в испытаниях, сгенерированных AI
Испытания с AI могут быть неточными, часто подтверждая существующий код, недостатки и все, а не предполагаемое поведение. Это приводит к двум основным категориям проблем.
Недостаток 1: синтаксически правильный, семантически неправильный
ИИ может генерировать код, который компилирует и использует тестирующие аннотации (например, @Test), казалось бы, сохраняя значительные ручные усилия. Однако правильность далеко не гарантирована. Разработчики, рассматривающие испытания, сгенерированные AI, должны следить за:
- Выглядит правильно, работает неправильно: ИИ превосходит в синтаксисе, но компилируемый код не приравнивается к логике тестирования звука или тестированию, который проверяет что -либо значимое.
- Неполные тесты: Это частая проблема, в которой ИИ устанавливает тестовый сценарий и вызывает метод, но пропускает решающий шаг проверки.
- Нет утверждений: Тест без утверждений эффективно бесполезен. Модели ИИ часто забывают проверить результат.
- Слабые утверждения: Assertnotnull (результат) — это незначительное улучшение по сравнению с отсутствием утверждения, но не подтверждает правильность результата. Точно так же Asserttrue (true) не предлагает ценности.
- Эксклюзивность счастливого пути: ИИ имеет тенденцию проверять самый простой, самый простой случай, часто пренебрегая нулевыми входами, условиями ошибки и краевыми случаями, если это явно не подсчитано.
- Нерелевантные или «галлюцинированные» тесты: ИИ может генерировать тесты для сценариев, которые являются бессмысленными для применения, или сосредоточиться на тривиальных деталях вместо значительного поведения.
- Тонкие логические ошибки: К ним относятся неверная установка (например, неправильная насмешка, инициализация тестов в неверном состоянии) или ошибочные утверждения (неправильные сравнения, не только ошибки).
- Тяжелые тесты: ИИ может бороться с тестами, связанными с параллелизмом или асинхронными операциями, что приводит к тестам, которые проходят или не имеют никаких непоследовательных сбоев из -за проблем с времени.
- Отсутствие контекстного понимания: Хорошие тесты часто требуют знаний, специфичных для домена. ИИ обычно не хватает глубокого контекста о конкретном применении, если не будет подробно проинформировано, что потенциально проверяет метод правильно в изоляции, но пропускает его более широкие системные последствия.
Недостаток 2: опасность проверки ошибок — проверка против проверки
Более коварная проблема возникает, когда тест AI, даже если технически верен для существующего кода, подтверждает неправильное поведение, поскольку сам код является глюком. Это подчеркивает решающее различие между проверкой и проверкой:
- Проверка: «Мы строим продукт верно?» Ведут ли код в ведении текущей реализации? ИИ может работать достаточно хорошо здесь.
- Валидация: «Мы строим правильный продукт?» Соответствует ли код искренне соответствует требованиям пользователя и правильно решает предполагаемую проблему? ИИ часто терпит неудачу в этой области.
Если метод CalculateTax содержит ошибку, которая приводит к отрицательному налогу для определенных входов, AI, анализирующий этот код
Разумно использовать AI с автоматической бдительности
Учитывая склонность к ошибкам, сгенерированным AI, ошибочна, интеграция инструментов статического анализа становится важной. Эти инструменты автоматически сканируют код — включая тесты — против обширных наборов правил, выявления потенциальных ошибок, уязвимостей безопасности и проблем качества кода.
Когда ИИ быстро вводит новый код, этот автоматический надзор действует как критическая проверка качества. Некоторые инструменты даже способствуют обеспечению ИИ, иногда с более строгим анализом, применяемым к сгенерированному AI-коду.
В дополнение к использованию статического анализа, разработчики также должны следовать этим лучшим практикам, если они хотят эффективно использовать генерацию тестов ИИ, не поддаваясь его подводным камням:
- Обязательный обзор человека: Это не подлежит обсуждению. Тщательно изучать AI-тесты для логического обоснованности, качества утверждения, выравнивания требований и охвата краев.
- Делегат мудро: Используйте ИИ для задач паттерной пластины, таких как генерация скелетов метода испытаний, базовая настройка/разрыв, простое издевательство или создание входных вариаций для существующих, доверенных тестов.
- Обеспечить богатый контекст: «Подсказка для мусора выдвигает испытания на мусор». Предоставьте ИИ соответствующую документацию, фрагменты требований и примеры высококачественных тестов.
- Быть явным в подсказываниях: Ясно инструктируйте ИИ о том, что тестировать, что издеваться и что утверждать.
- Итерация и уточнить: Обратитесь к выводу ИИ как первый черновик. Просмотрите, правильно и улучшите его.
- Освоить свои инструменты: Поймите нюансы выбранного вами инструмента ИИ. Узнайте его общие модели ошибок и эффективные стратегии подсказования.
- Начните с малого и контролируемого: Сначала экспериментируйте с генерацией тестов ИИ на некритических проектах, чтобы оценить его истинные преимущества производительности и кривую обучения.
ИИ как копилот, а не автопилот, при тестировании
Генерация тестов ИИ, несомненно, является мощной новой способностью, предлагая потенциал для ускорения создания тестов. Тем не менее, это не решение «Огонь и забыть». Модели ИИ, по их нынешнему характеру, могут создавать тесты, которые являются неполными, неверными или просто проверять существующие ошибки.
Ключ в том, чтобы рассматривать ИИ как интеллектуального помощника, а не непогрешимого эксперта. Позвольте ему обрабатывать элементарные задачи и повторяющиеся задачи, но всегда подвергайте его выходу в строгий обзор человека и автоматические проверки качества посредством статического анализа. Объединяя скорость ИИ с усердием разработчика и надежным инструментом, команды могут использовать преимущества генерации тестов, управляемых ИИ, не жертвуя целостностью и качеством своего программного обеспечения.
Sonar обеспечивает разработчиков и организаций для обеспечения качества, безопасного кода, подходящего для разработки и производства, будь то ИИ, сгенерированный или написанный разработчиками. Сонар, которому доверяют более 400 000 организаций по всему миру для очистки более половины триллионных строк кода, является неотъемлемой частью обеспечения программного обеспечения. Insight Partners является инвестором в Sonarsource и TNS. Узнайте больше последних из Sonarsource Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джонатан Вила Лопц является защитником застройщика в Sonar. Он является чемпионом Java и соучредителем конференций в Испании Jbcnconf и Devbcn, организаторе группы пользователей Barcelona Java (кувшин) и член Barcelonajug. Он также был … Подробнее от Джонатана Вила Лопц
