Transcription
Написание тестов обычно не является любимой частью работы разработчика. Но что, если бы я мог написать свой тест, просто описав, чего я хочу, на обычном английском или естественном языке? Ну, в сегодняшнем видео я покажу вам, как использовать разработку, управляемую подсказками, для создания и, надеюсь, полного рабочего набора тестов для веб-приложения, которое я создал с помощью Golang. Давайте приступим и посмотрим, как далеко мы сможем зайти. Итак, прежде чем мы перейдем к разработке, управляемой подсказками, и начнем использовать GitHub Copilot для создания действительно классных тестов для этого приложения, я подумал, что было бы неплохо фактически пройтись и показать, что именно делает это приложение. Итак, как и во многих погодных приложениях, у вас будет пользовательский запрос, который поступает. Мы используем Go. Поэтому мы перейдем в файл main.go, который является основным файлом для большей части этого приложения. Он вызовет файл конфигурации. Так что загрузите ключ API, общую конфигурацию, все, что нам нужно. Итак, здесь мы называем этот файл, чтобы получить все, что нам нужно. Оттуда мы создадим погодный клиент. И этот погодный клиент затем определит, используем ли мы пользовательский интерфейс или приложение для погоды на основе командной строки в данный момент. Затем он получит данные с помощью вызова API из API open weather map и вернет их в формате JSON. Так что это даст нам такие вещи, как влажность, температура, местоположение и все в этом роде. Так что это, на первый взгляд, то, что происходит. Теперь, чтобы вы увидели, как это выглядит на самом деле, я открыл это в простом браузере в VS Code. Если я хочу узнать, какая сейчас погода в Лондоне, я введу Лондон и нажму поиск. 16° C. Довольно просто. Но теперь нам нужно использовать некоторые подсказки, чтобы сгенерировать тесты и дать нам хорошую основу для работы в качестве разработчика. Итак, разработка, управляемая подсказками, заключается в том, чтобы направлять LLM или ИИ-помощника для создания целенаправленного кода на основе описаний. Так что вместо того, чтобы я писал каждую строку кода, я пишу на естественном языке, а ИИ-помощник пишет это для меня, но я направляю его. И есть много обмена. Так что позвольте мне показать вам, как это сделать или что я собираюсь сделать. Итак, прежде всего, я в VS Code и собираюсь открыть окно чата с GitHub Copilot. Итак, мой режим агента здесь. Убедитесь, что он в режиме агента, и я выберу, я оставлю его на Claude Sonic 4.5. Давайте немного повеселимся. Итак, подсказка, которую я собираюсь использовать, это создать пустой набор тестовых файлов для всех файлов, для которых мне нужно написать модульные тесты в этом приложении. Теперь, до написания этого, у меня также есть файл agent.mmd, который описывает все, что мне нужно было знать о тестовом фреймворке, который я хочу создать. Так что я описал пирамиду тестирования. Так что сквозные тесты, интеграционные модульные тесты и т. д. Я даже описал, как именно я хочу, чтобы эти тесты были написаны. Так что стандартный формат теста, у меня будет имя функции. Затем я устрою это. Так что у меня будет действие, выполнение, а затем утверждение и проверка результатов. Очень типично для того, что вы делаете во многих тестах. Итак, я действительно даю ему понимание и основу того, чего я ожидаю от него. Так что это еще одно средство руководства. Итак, давайте выполним эту команду. Итак, я скажу: создайте пустой набор тестовых файлов для всех файлов, для которых мне нужно написать модульные тесты в этом приложении. И, надеюсь, он возьмет в качестве ссылки мой файл agents.mmd и начнет писать именно то, что, по его мнению, мне нужно сделать. Так что я не прошу его писать тесты в данный момент. Я просто направляю его и пытаюсь заставить его написать или создать эти файлы для меня. Те, для которых я знаю, что мне нужно писать тесты. Отлично. Итак, теперь мы видим, что он закончил писать или создавать эти пустые тестовые файлы для меня. Он дал краткое описание того, что он сделал. Так что вы можете видеть, что он создал config test, server test, cli test и т. д. И все это в моей директории. Но если бы я заглянул в один из них. Итак, давайте возьмем server test.go. Вы можете видеть, что есть много todo. Он спрашивает или говорит мне, что это тест, который мне нужно написать. Тест для нового сервера. У нас также есть тест handle, является ли API успешным. И я уверен, что где-то здесь, вероятно, будет и недействительный. Но вы можете видеть, что он создал эти тестовые файлы для меня. Он дал мне отличную основу для дальнейшей работы. И я выберу пару этих тестов, которые я хочу написать с Copilot через мгновение. Но давайте копнем немного глубже и посмотрим, есть ли здесь что-нибудь еще, что он сделал. Все выглядит довольно стандартно, и есть несколько пропусков. Так что мы можем видеть, что они еще не реализованы. Так что, как только они будут реализованы, мы сможем отменить пропуск этого теста. Это очень нормальное поведение для любого разработчика. Мы всегда видим, как люди пропускают тесты. Copilot здесь абсолютно ничем не отличается. Я собираюсь сохранить их, потому что они выглядят хорошо для меня. Итак, наша следующая задача — фактически написать некоторые тесты, потому что если бы я запустил это и скомпилировал этот набор тестов, все, конечно, прошло бы. Ничего бы не провалилось. Все это todo. Все пропущено. Там ничего нет. Они просто существуют в файле. Так что на самом деле нам нужно пойти и создать их. Теперь я думаю, если мы посмотрим на weather test.go, это фактически то место, где мы делаем запрос API к open weather map. Так что это место, где мы будем получать данные и возвращать их. Так что я думаю, это отличный пример, чтобы увидеть, можем ли мы написать тесты, которые, возможно, включают некоторое мокирование. Так что в моем файле agents.md у меня есть стратегия мокирования, которую я написал. И мок-клиент позволит нам не запускать сервер во время выполнения набора тестов. Так что серверу не нужно быть запущенным для прохождения тестов и получения мок-данных. Так что это, по сути, то, что мы делаем здесь. Так что я написал стратегию мокирования, и это, вероятно, будет очень хороший способ протестировать это и посмотреть, как далеко мы сможем зайти с copilot. Теперь я собираюсь написать подсказку: сделайте мне несколько модульных тестов для погодного API. Очень расплывчато, но довольно прямолинейно, потому что у меня так много контекста вокруг этого. Мне не нужно писать действительно подробные подсказки. Используйте стратегию мокирования, которую я описал, для мокирования любых данных, необходимых для запроса REST. Так что это действительно удвоит тот факт, что я хочу, чтобы он мокировал данные, а не пытался запустить тест, который запускает клиент, сервер и все остальное, что с этим связано, только для цели теста. Итак, давайте посмотрим, сможем ли мы заставить его написать тесты для нас. Надеюсь, он поймет, что я нахожусь в weather test.go, а не пытаюсь создать большой и сложный набор тестов. Но посмотрим. Я был довольно расплывчатым с этой подсказкой, и давайте посмотрим, как далеко мы сможем зайти. Это здорово. Он уловил все, что мне было нужно. И я был очень расплывчатым с моей подсказкой, но я пытаюсь направить его, используя множество различных контекстов как из окна чата, так и из моего файла agent. И что ему удалось сделать, так это то, что он понял, что я хочу тестировать только в файле weather test.go. Никакой другой файл не был затронут. Он фактически создал для нас мок-сервер. Здесь мы видим, что он создал этот мок-сервер http test new server. Он как бы содержится в себе. И он возвращает нам много мок-данных, что блестяще. Это именно то, что я хотел. Похоже, у него нет ошибок компиляции с точки зрения синтаксиса. Итак, мы найдем и посмотрим, что происходит с точки зрения тестов. Они вроде как все написаны. Все они используют мок-сервер, что отлично. Они все получают это. Они как бы возвращают данные. Этот здесь — ошибка API. Так что мы ожидали бы 401. Да. Тестируйте любые четверки или пятерки. Так что 401, 429 и 500. Он также использовал табличное тестирование. Так что он уловил из моего файла agent.md, что в моей стратегии я попросил его использовать формат табличных тестов. Так что здесь мы видим, что у нас есть несколько входных данных на тест, позволяющих тестировать несколько раз, а не иметь много разных тестов за один раз. Итак, давайте запустим этот тест и посмотрим, пройдет ли он. Итак, мы позволим Copilot написать команду терминала. Итак, go test. У нас будет подробный вывод. Так что у нас будет D минус D. Отлично. Похоже, он проходит. Прекрасно. Ладно, блестяще. У нас есть проходящий набор тестов. И, конечно, как разработчик, я теперь зайду и посмотрю, что происходит. Была ли какая-либо дополнительная доработка, нужно ли что-то привести в порядок, все в этом роде. Как разработчик, я теперь могу зайти и внести изменения. Мы просто позволим ему закончить здесь и сделать то, что он делает. Итак, похоже, что он ранее не смог понять форматирование JSON. Так как мы хотим получать JSON из каждого запроса, мы хотим убедиться, что форматирование хорошее, особенно для CLI. И, конечно, структура и все, во что мы будем помещать или отображать это в программе. Так что он уловил это. Он смог его доработать. И теперь, конечно, давайте снова запустим тест и посмотрим, изменилось ли что-нибудь. Похоже, ничего не изменилось, что блестяще. Так что мы можем фактически перейти и просто остановить это. Мы можем получить покрытие тестов, все в этом роде, но мы не будем. Я просто пропущу их, а затем остановлю Copilot. Он сделал все, что мне нужно для этого одного тестового файла, что блестяще. Итак, после всего этого, я думаю, осталось только одно, и это создать остальную часть набора тестов. Итак, я снова напишу довольно расплывчатую подсказку, и я скажу: напишите полный набор тестов для всех оставшихся тестовых файлов. Включите покрытие кода, чтобы мы знали, сколько кода тестируется. И это должно быть довольно общее заявление, просто чтобы сказать: эй, copilot, я теперь дал тебе файл agent.md. Я дал тебе текущий тестовый файл, который является weather test. Я показал тебе или попросил тебя создать мок-данные и мок-тесты с этим сервером, и иди и создай все остальное сейчас. Надеюсь, он сможет это сделать. Довольно просто. Хорошо, прекрасно. Итак, похоже, он прочитал кодовую базу, понял, что ему нужно сделать, и создал config test или модульный тест в файле конфигурации, тест для файла сервера и тест для файла CLI. Так что мы можем перейти и просто нажать на них. Мы можем посмотреть, что он там делал. И вы можете видеть, что он удалил пропуск, как и раньше. И он добавил ряд различных тестов для нас, снова используя формат табличных тестов, как я описал в agents.d. Итак, давайте позволим этому. Давайте запустим некоторое покрытие тестов и посмотрим, какое покрытие у нас теперь есть. Прекрасно. Похоже, у нас есть несколько неудачных тестов. Теперь это действительно хорошая возможность показать, как Git Copilot будет итерировать по этим неудачным тестам и посмотреть, что ему нужно сделать, чтобы исправить их. И вот оно. Он распознал тот факт, что у меня есть ключ API в моем файле M. Очевидно, будут некоторые проблемы с запуском тестов с файлами M, потому что, очевидно, у меня есть ключи API и все такое. Так что ему нужно выяснить, как это исправить. Так где он загружает его должным образом, загружает ли он его или нет, и т. д. Хорошо, похоже, он что-то исправил в сквозном тестировании и в config test. Так что давайте снова запустим покрытие, чтобы увидеть, какое у нас покрытие, и посмотрим, проходит ли оно. Хорошо, похоже, у нас 90% покрытия определенных утверждений. Так что я предполагаю, что это фактически, похоже, 90% утверждений, 90% покрытия в большинстве случаев. Но есть О, так это только погодное приложение, но оно все еще где-то терпит неудачу. Так что он, очевидно, выяснит, да, у нас все еще есть проблема с файлом M. Так что давайте позволим этому, но он просто выведет именно то, что происходит с файлом M. Я прочитаю этот вывод в себя и попытаюсь помочь выяснить, что происходит. Так что он все еще говорит, что файл M существует. Тесты нужно временно переименовать, чтобы игнорировать его. Давайте просто обновим имя и обработаем его должным образом. Так что мы увидим, как он с этим справится. Очевидно, как разработчик, я вернусь и внимательно изучу, что именно он делает и как он это делает. Так что мы снова запустим покрытие тестов. Отлично. Это выглядит намного лучше. У нас теперь есть проходящий набор тестов, что отлично. И теперь он спросит, что он просто пытается сделать все эти дополнительные вещи, которые вы можете делать с Go. Вы можете вывести и сделать что-то вроде профиля покрытия или файла покрытия тестов MD, все эти классные вещи. Так что мы не будем беспокоиться об этом. У нас есть все, что нам нужно. У нас есть полный набор работающих тестов на данный момент. Теперь я перейду и проверю их и посмотрю, что нужно сделать с точки зрения разработчика. Так что мы пропустим это, а затем завершим copilot. Итак, вот оно. Это то, что мы используем как разработку, управляемую подсказками, чтобы помочь написать набор тестов с GitHub Copilot внутри VS Code, просто используя много контекста и много доработки. Итак, у нас есть отличные тесты от сквозных тестов. У нас есть куча модульных тестов. И, судя по всему, у нас также есть интеграционные тесты. Если вам понравилось это видео, если вы чему-то научились, поставьте лайк, подпишитесь и посмотрите другие наши видео. Увидимся в следующем.