Прибыль:
- Способность проводить модульное тестирование, анализ крайних случаев и анализ пробелов в покрытии с помощью ИИ.
- Возможность распечатать тестовые ожидания на основе спецификации, а не текущего поведения кода.
- Возможность проверить, действительно ли тест защищает, путем внесения ошибок.
Написание тестов — одна из наиболее полезных задач, которую большинство разработчиков откладывают. Хороший набор тестов — это доказательство того, что код работает должным образом, и спасательный круг для будущих изменений. Проблема в том, что написание тестов — это повторяющийся процесс, отнимающий много времени, а это именно та работа, в которой ИИ сияет. Но есть одна загвоздка: ИИ часто тестирует существующее поведение кода, а не то, каким оно должно быть. Управление этой разницей является сутью данного блока.
В этом модуле вы изучите модульное тестирование (тестирование, при котором проверяется отдельная функция), тесты на крайние случаи и генерацию тестовых данных с помощью ИИ; устранение пробелов в тестовом покрытии; и почему слепо доверять тестам ИИ опасно.
Две стороны тестирования: исправление поведения и проверка
Тест может служить двум разным целям. Первый — проверка: он проверяет правильность кода и его соответствие спецификации. Второй — регрессионная защита: она замораживает поведение кода сегодня, поэтому, если кто-то случайно изменит его завтра, тест прервется и оповестит.
ИИ очень хорош в последнем; Он просматривает код и генерирует случаи, которые проверяют, «что он делает прямо сейчас». Но если код неверен с самого начала, ИИ может посчитать такое неправильное поведение «правильным». Поэтому вы должны просмотреть утверждение каждого теста, который производит ИИ: «Код возвращает 42, а тест ожидает 42» не означает, что 42 — правильный ответ.
Внимание: если ИИ проходит тест, это не означает, что код «работает»; это просто означает «он ведет себя так, как ожидает ИИ». Вы решаете, верны ли ваши ожидания, просматривая спецификацию.
Шаг за шагом: написание надежных тестов с помощью ИИ
- Дайте спецификацию, а не только код. Если вы добавите информацию «Эта функция должна сделать это», ИИ сможет написать правильное ожидание; Он проверит текущее поведение, если вы просто предоставите код.
- Спросите о крайних случаях. Пустой, нулевой, нулевой, отрицательный, слишком большой, неправильный формат, параллелизм — явно отказывайтесь от счастливого пути.
- Укажите структуру и стиль тестирования. «использовать pytest», «шаблон Arrange-Act-Assert», «пусть каждый тест проверяет что-то одно» и т. д.
- Проверьте ожидания (утверждение). Сравните со спецификацией, которую каждое утверждение проверяет на правильность значения.
- Устранение пробелов в сфере охвата. Дайте существующие тесты и спросите "какие ветки и кейсы не тестировались?" заставить вас спросить; затем проверьте дополнительные проведенные тесты.
Три мини-кейса
Случай 1 — Охват от 52% до 85%. Покрытие тестами одного сервисного модуля составило 52%. Команда передала существующие тесты ИИ, попросила его составить список непроверенных ветвей и сгенерировать для них тесты. После проверки людьми охват увеличился до 85%; В процессе ИИ обнаружил фактическую ошибку (путь, который возвращал неправильный код ошибки) в ветке ошибок, которая никогда раньше не тестировалась.
Случай 2. Ловушка фиксации ложных ожиданий. Функция округления денег на самом деле работала неправильно; Вместо округления 2,675 до 2,67 вместо 2,68 округлялось 2,67. ИИ посмотрел код и написал Assert round_money(2.675) == 2.67 — зафиксировав ошибку как «истину». Когда разработчик прочитал спецификацию, он исправил ожидание и обнаружил настоящую ошибку. Решающее значение имело тестирование правила, а не кода.
Случай 3 — Взрыв пограничного состояния. При запросе у ИИ только «краевых случаев» для функции диапазона дат; Было получено 8 случаев, таких как начало = конец, обратный интервал, високосный год 29 февраля, разные часовые пояса и нулевой интервал. Два из них (обратный интервал и високосный год) фактически вызывали ошибку. Рассмотрение этих случаев вручную часто пропускают; ИИ стал здесь партнером по «мозговому штурму».
Четыре копируемых шаблона
Генерация тестов на основе спецификаций:
Роль: Разработчик, который пишет тесты. Платформа: {{pytest/JUnit/Jest...}}. Что ДОЛЖНА ДЕЛАТЬ функция (спецификация): {{rule}} Напишите тесты для следующей функции. Пишите ожидания согласно спецификации, а НЕ текущий вывод кода. Счастливый путь + добавьте как минимум 4 крайних случая. Пусть каждый тест проверяет что-то одно, используйте описательное название. {{функция}}
Крайний случай мозгового штурма:
Перечислите крайние случаи/сбои, которые следует опробовать при тестировании этой функции (нуль, ноль, точки останова, неверный формат, параллелизм, внешняя ошибка). Для каждого случая: входные данные, ожидаемое поведение. НЕ пишите пока код, просто перечислите.{{function}}
Анализ пробелов в покрытии:
Ниже приведены функции и доступные тесты. Какие отрасли, условия и случаи не были проверены? Перечислите недостатки и напишите новые тесты только для этих недостатков. Не повторяйте существующие. Функция:{{function}}Тесты:{{existing_tests}}
Тестовые данные/генерация макета объекта:
Создавайте реалистичные тестовые данные для тестов {{функции/сервиса}}: действительные образцы, граничные образцы и недействительные образцы отдельно. Предложите простой макет поведения для внешней зависимости {{X}}. Использование истинно конфиденциальных данных/PII; Генерировать фейковые данные.
Слабая подсказка / Сильная подсказка
Слабое: «Напишите тест для этой функции».
Strong: "с pytest. Функция apply_discount(total, процент) — правило: скидка должна быть 0%–30%, за пределами границ должно выдаваться ValueError, результат должен быть округлен до 2 десятичных знаков. Пишите ожидания по этому ПРАВИЛУ (не по коду). Счастливый путь + эти крайние случаи: 0%, 30%, 31% (ошибка), отрицательный, итог = 0. [код]"
Он дает строгое правило выпуска и говорит: «Пишите ожидание в соответствии с правилом, а не кодом»; Это единственное предложение закрывает ловушку, в которой ИИ исправляет плохое поведение.
Тип теста
Вклад ИИ
человеческий контроль
Удачных дорожных испытаний
быстрый скелет
Верны ли ожидания?
Краевые случаи
Обширный мозговой штурм
Устраните ненужное
Заполнение пробелов в сфере охвата
Находит пропущенные ветки
Подтвердить значимость
Тестовые данные/макет
Создает реалистичный образец
Нет личных данных, контроль реализма
Тесты управляют качеством, а не гарантируют его
Высокое покрытие тестами дает уверенность, но оно также может вводить в заблуждение: 100-процентное покрытие означает, что «каждая строка была пройдена», а не «каждая строка правильна». Увеличить охват с помощью ИИ легко; Настоящая ценность заключается в написании осмысленных ожиданий. Ценность теста заключается в его способности ломать код и предупреждать вас, когда код сломан. Вот почему тесты, генерируемые ИИ, основаны на вопросе «действительно ли код ломается при его изменении?» Проверьте это с помощью вопроса; Намеренное нарушение линии и наблюдение разрыва теста (идея мутации) является доказательством того, что тест сработал.
Совет: Чтобы проверить, работает ли тест, который пишет ИИ, создайте небольшую ошибку в коде (например, измените + на -) и посмотрите, не сломается ли тест. Если он не сломается, этот тест вас не защитит.
Распространенные ошибки
- Просить тест без указания правила. Модель замораживает текущее поведение; исправляет ошибку как «истину».
- Принимать ожидания, не читая их. Тестирование вводит в заблуждение, если вы не проверите, что утверждения проверяют правильное значение.
- Просто проверяю счастливый путь. Настоящие ошибки живут на полях; Явно запрашивайте крайние случаи.
- Ошибочное назначение цели. Высокий процент не является гарантией правильного поведения.
- Превращение реальных/скрытых данных в качестве тестовых данных. Данные или секреты клиентов не должны подвергаться тестированию и хранению; Генерация синтетических данных.
В заключение
ИИ берет на себя большую часть повторяющейся нагрузки при написании тестов: он создает быстрые скелеты, большие списки крайних случаев и анализ пробелов в покрытии. Но самый критический момент — ожидания: ИИ склонен тестировать текущее поведение кода, тогда как тестирование должно быть написано по спецификации. Создайте правило, проверьте ожидания, реализуйте крайние случаи и проверьте, действительно ли тесты защищают, внося ошибку. Тестовое покрытие — это инструмент, а не цель.
Задача приложения
Выберите функцию и сначала распечатайте тест для ИИ, просто указав ее код; Обратите внимание на ожидания. Затем снова распечатайте тест, указав спецификацию (необходимое поведение) для той же функции. Сравните ожидания от двух тестовых наборов: есть ли разные, какой из них выявляет реальную ошибку? Наконец, убедитесь, что один из сгенерированных тестов сработал, добавив в код преднамеренную ошибку и увидев сбой теста.
контрольный список
- [ ] Я различаю, предназначен ли тест для исправления или проверки поведения.
- [ ] Когда я запрашиваю тест, я указываю правило (спецификацию), которое должно быть установлено, а не код.
- [ ] Я сравниваю каждое сгенерированное утверждение со спецификацией.
- [ ] Я явно запрашиваю крайние случаи и случаи сбоя.
- [ ] Я рассматриваю процентное покрытие как инструмент, а не цель.
- [ ] Я проверяю, действительно ли тест защищает, путем внесения ошибок.