Comments 49
Отлично, прямой конкурент для Github Copilot. Такими темпами оно станет скоро бесплатным и безлимитным.
Оставшись бесполезным
Ну, зря Вы так: он хорошо пишет комментарии в коде и неплохо генерирует процентов девяносто юнит-тестов.
Ага, комментарии уровня: "Это стул, на него обычно садится человек" - лишний шум
А юнит тесты, хз как можно писать с помощью АИ. Юнит тест - это на основе своего внутреннего понимания задачи - сломать код. Аи по запросу "напиши тесты" этого делать не будет. Нафиг такие тесты
Единственная сила аи - авто и комплит
Да, нет же, хорошо описывает. Если нужно подробно (что лично я не люблю), то умеет и так.
Немного Вас не понял... Он хорошо юниты на эдж-кейсы делает. Например, если метод принимает X [1..10], то он сгенерирует тесты на 0, 1, 10 и 11.
Какие же это edge-cases, ха. Вот edge-cases: 1e100, 0.1, "foo", null.
Вообще, стараться специально поломать ваш код угодливый T9 не станет: попробуйте заставить его в TDD, например.
Зато люди триста лет назад придумали property-based tests.
Ваши примеры для языков без статического контроля типов. В Delphi если вместо Integer подсунуть Double или строку - даже не скомпилируется.
Во-первых, я что-то не вижу тега «Delphi» в шапке. Во-вторых, 1e100 — это целое, его можно напрямую привести без потери точности.
Там ниже Visual Studio 2022 обсуждают, тоже вроде нет в шапке. Зато есть общий тег Programming. А 1e100 - это константа из какого целочисленного типа? Вы же понимаете, что целочисленная константа может принадлежать к определённому целочисленному типу, только если попадает в диапазон его значений?
В статически типизированных языках попытка присвоения такого значения целочисленной переменной отлавливается на раз. Ну а Python сам сменит тип переменной после присвоения на подходящий.
Куда чего питон сменит? Само по себе 1e100 — float, какой бы ни была мантисса, это понятно. Я ж говорю: «привести».
>>> import math;
>>> math.floor(1e100)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104И вообще, ну я же просто привел примеры того, что надо тестировать. Тестировать 0 и 1 — бессмысленно, если код писал человек, хотя бы поверхностно знакомый с азами: там ошибок не будет.
Даже если эти примеры это пайлоад в ресте? Неужели в входном json'e нельзя подсунуть строку вместо числа?
Это был строго синтетический пример. Ну, а т.к. я пишу на .NET C#, то пример был для него. Прошу прощения, что не указал отдельно. Как правильно написал хабровчанин ниже, тесты с Вашими входными параметрами не смогли бы скомпилироваться в дотнете.
Да какая разница, зачем цепляться именно к этому примеру? Вы просто за деревьями лес не видите.
Ну пусть это будет не целое, которое завернет компилятор, а строка. Так вот тестирование на пустой строке — это не edge case. Edge case — это невалидная UTF-8 строка, строка с бинарным нулём, строка длиной гигабайт и так далее.
Первостепенная задача юнитов проверить валидные кейсы, а не что-то там ломать.
Если метод не работает при валидных данных, абсолютно все равно как он работает на не валидных.
Проверять валидные кейсы за разработчиком, вкатившимся более недели назад, — бессмысленно. Люди способны имплементировать success path почти всегда (кроме клинических случаев).
А вот неочевидные подводные камни — не всегда, именно отсюда TDD родился.
Проверка крайних случаев это не единственная задача юнит тестов.
Представьте что вы будете добавлять тест на обработку строки длиной в гигабайт для каждой функции, которая принимает строку. Это возможно, а имеет ли смысл?
Основная функция юнит теста это фиксация поведения. Это позволяет расширять или рефакторить код более уверено. Вы упоминали snapshot testing, но он хорошо работает только для чистой функции. А если нужно проверить, что определенная функция была вызвана в определенный момент с определенными аргументами?
ChatGPT позволяет мне быстро зафиксировать поведение функции / класса. После первого раунда, я глазами пробегаюсь и прошу догенерировать конкретные кейсы. Чаще всего получается быстрее, чем мануально. При этом моя голова тоже работает.
если нужно проверить, что определенная функция была вызвана в определенный момент с определенными аргументами?
Для этого лучше всего подходят моки.
Разумеется. Просто я хотел подчеркнуть что проверка крайних случаев это только одна из задач юнит тестирования. И что даже если ChatGPT не очень силен в этом (в том числе потому что среднестатистический разработчик не очень силен в этом), то другие аспекты он покрывает достаточно хорошо, а потому полезен. Он снимает с меня исполнительскую нагрузку, оставляя только аналитическую.
Я не хочу подробно, я хочу "полезно". Что такое "полезно" вопрос открытый.
Отлично, он напишет тесты на корнер кейсы так, что тесты зеленые. Где в этом действие умственные усилия по проверке, что код верен? Я уж не говорю про тривиальность примера
Я не говорю, что аи бесполезен, просто логика использования совсем не к месту
Опять не завезли поддержку Visual Studio 2022. Кто-то в курсе, почему все плагины ассистов (континум, сбер, яндекс, гугл, джуни) делают только под вскод или джетбрейнз? У студии явно немалая доля юзеров, почему их (нас!) динамят?
Да закопает ее MS, флагманский редактор VS Code у них
Или Raider :)
Сильное заявление О_о Насчет Rider согласен, сам сидел на нем, пока JB не прикрыли как раз обновление плагинов. Пришлось свичнуться обратно на VS 2022, с которой ушел еще со времен 2017, и, в принципе, не то, чтобы страдаю) Но странно сравнивать ее с ноутпадом, которому завезли solution explorer)
Что-то вокруг VS Code много хайпа, пытался в нем что-то делать, не понял, как это можно сравнивать его с полноценной IDE, да хоть с Rider, хоть с Visual Studio.
Да у него много плюсов - VS Code легкий и быстрый, кроссплатформенный и все.
Когда упрётесь в удаленную отладку Wibdows сервиса, писаного хоть на C++, хоть на .NET, или отладку параллельных вычислений, в специфику какой нибуть экзотики и т.п. поймёте, что просто классного и легкого редактора для этого мало.
Это как сравнивать эндуро мотоцикл с экскаватором. Да на экскаваторе не удобно за пивом ездить, это долго и дорого, но есть не малый пласт задач, где без экскаватора и можно обойтись, но будет долго и больно, проще потратить 2 дня на то, чтобы завести экскаватор и потом за день сделать то, что будешь на мото и руками делать месяц.
Будут они долго и счастливо жить параллельно, ибо это совсем разные вещи, для разных целей, нельзя их даже сравнивать.
С другой стороны, не всем нужен экскаватор и если хватает VS Code для все дел, то действительно полноценная IDE не нужна и это будет правильно и эффективно.
Тоже глубоко сожалею, попробовал прямо счас его в VS Code на C#-проекте: классные интеграции предлагаемых доработок - дифф с текущим файлом, инсерт в него же и т. п. Наверно у нас так может Копайлот, но лень заморачиваться с оплатой)
Потому что Visual Studio 2022 крутится около .NET проектов, а VS Code можно подрубить под написание кода любой экосистемы, или отсутствующей таковой. Возможно, для разработчиков плагинов не надо отстегивать MS на интеграцию в VS Code.
Интересно, что даже в Delphi 12.2 появилась встроенная интеграция с движками AI, как локальными Ollama, так и облачными (OpenAI, Gemini и Claude).
Хм... А Gemini, идущий "в комплекте" с Android Studio, - не он ли?
Точно бесплатный? В vs code плашку выдал - You are missing a valid license for Gemini Code Assist and may lose access to the service. Contact your billing administrator to purchase or assign a license.
Мне кажется гемини худший вариант для кода, если брать для сравнения OpenAi и Claude.
Я помню пробовал использовать его для генераций xpath-ов. Полная фигня, часто генерит просто никуда не ссылающиеся выражения. А надежд то былооо...
после установки он почему-то предлагает To use Gemini Code Assist Standard or Enterprise, you need to select a Google Cloud project. Хотя на youtube глянул, там ничего подобного не требуется.
Google предлагает разработчикам бесплатный инструмент на основе ИИ для программирования