Table-test или как помочь агенту понять как тестироваться

В сфере искусственного интеллекта произошло заметное событие. ZergsLaw только что Table-test или как помочь агенту понять как тестироваться Простой 3 мин 0 Go * Тестирование IT-систем * Туториал Агенты сейчас пишут тесты уже за многими из нас, будем объективны, все больше людей кидаем таску ему - получают пачку аппрувов и погнали все это мержитьНо есть, скажем так, ненулевой шанс, что сгенерированные тесты окажутся произведением искусства мусором, который ничего не проверяет (и нет, не шутка, мне коллеги буквально показывали тесты где просто вызывается функция и проверяется что ошибка nil и на этом все, а результат просто всегда игнорировался)И в таких кейсах очень классная картина: у вас зеленный CI, прод сломан, и вопрос:И вот в чем суть, программиста от вайбкодера отличает в первую очередь понимание, а что делает агент и как подправить его проблемы? Поэтому понимать, как тесты устроены, всё ещё нужно - даже если руками вы их больше не набираете :)Текст в первую очередь для тех, кто переходит на Go с других языков. Ну и для начинающих гоферов тоже.

Меня зовут Эдгар Сипки, я founder easyp & sipki tech и отбираю доклады на Golang Conf в программном комитете. А в своём тг-канале делюсь прикладными Go и LLM - инструментами и подходами для разработки - подписывайтесь, дальше будет больше :)Зачем вообще таблицыСамый популярный паттерн написания тестов в Go - это табличные тесты. Идея на самом деле простая, вместо десяти почти одинаковых тестов вы пишете один, а все вариации складываете в таблицу.

Технические детали

Новый кейс - одна строка, то есть что входящие, что исходящие значения тестируемой логики прописываются параметрами тест кейсаВторая ценность - скорость, что очень важно особо на больших проектах, ведь каждый тест кейс вы можете запустить конкурентно, где каждый тест становится subtest-ом через t. Parallel() , удобно перезапустить изолировано, самое важное не забывать про вызовы t. Helper() иначе дебагинг тестов станет отдельном котлом в адуfunc TestParseAmount(t *testing.

Parallel() type testCase cases := testCase{ {in: "100", want: 100}, {in: "1_000", want: 1000}, } for _, tc := range cases { t. Run("", func(t *testing. want, ParseAmount(tc.

in)) }) } } К примеру, тут тип testCase живёт внутри теста и никому не мешает, но можно вынести структуру на уровень пакета. Звучит как чистая архитектура? Да и логично, зачем объявлять типы в тестеМожно вынести структуру на уровень пакета.

Отраслевые последствия

Звучит как чистая архитектура? // Тип занят первым тестом... а второму нужна своя структура.

type testCase2 func TestParseAmount(t *testing. T) { /* использует testCase */ } func TestFormatAmount(t *testing. T) { /* использует testCase2 */ } Тип нужен ровно одному тесту, а живёт на уровне пакета, а второй тест хочет свою структуру - и начинается: testCase2, parseTestCase, formatTestCase...

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.