Написание тестов через ИИ
Когда начинаешь подключать ИИ к решению задач, первое, что хочется это конечно что-то автоматизировать, и хочется автоматизировать рутину. Например, писать тесты долго, а пользу от них в команде просто не видят, особенно если это не их код и не их фича.
Например, есть юнит-тесты с чёткой целью: хороший юнит-тест = быстрый тест, который работает как индикатор и сразу подсвечивает проблемное место. Когда тест падает, ты сразу знаешь, в какой именно функции проблема. Тут конечно считаю, что скоростью должен обладать любой хороший тест.
На проектах их пишут иногда по требованию клиента, потому что у него так покрываются все продукты. Нужно закрыть тот процент, который требует клиент, например 70%, и добавлять тесты к каждой новой фиче или странице. По большому счёту это "тесты ради тестов", то есть ради достижения цифры, а не ради той самой функции индикатора, ради которой они вообще задумывались.
Параллельно на некоторых проектах сейчас внедряем тесты там, где их вообще не было, и пишем сразу e2e. Причина в том, что юниты проверяют реализацию, а с ИИ реализация не имеет значения, она меняется каждую генерацию. Смысл есть только в проверке поведения снаружи. И конечно, тест-кейсы для этого стоит вести в системе управления, а не хранить в разрозненных файлах.
Когда убираешь рутину, заодно появляется шанс перейти на следующий этап и уйти от старой привычки к новой. Это не то, что до ИИ никто не знал, все эти принципы тестирования существовали и раньше. Просто в текущих реалиях это уже договорённость: раз ИИ может быстро писать e2e, ограничение "дорого и долго" затирается. Классическая тестовая пирамида, где юнитов много, а e2e совсем чуть-чуть, отражала ограничения инструментов своего времени, когда e2e были медленными и дорогими в поддержке. Сейчас это ограничение снимается, и ромб подходит лучше, чем пирамида: юниты остаются основой, но доля e2e растёт, потому что инструменты для них стали быстрыми и дешёвыми, и держать их наверху пирамиды просто по привычке больше не обязательно.
#ai #tests
Когда начинаешь подключать ИИ к решению задач, первое, что хочется это конечно что-то автоматизировать, и хочется автоматизировать рутину. Например, писать тесты долго, а пользу от них в команде просто не видят, особенно если это не их код и не их фича.
Например, есть юнит-тесты с чёткой целью: хороший юнит-тест = быстрый тест, который работает как индикатор и сразу подсвечивает проблемное место. Когда тест падает, ты сразу знаешь, в какой именно функции проблема. Тут конечно считаю, что скоростью должен обладать любой хороший тест.
На проектах их пишут иногда по требованию клиента, потому что у него так покрываются все продукты. Нужно закрыть тот процент, который требует клиент, например 70%, и добавлять тесты к каждой новой фиче или странице. По большому счёту это "тесты ради тестов", то есть ради достижения цифры, а не ради той самой функции индикатора, ради которой они вообще задумывались.
Параллельно на некоторых проектах сейчас внедряем тесты там, где их вообще не было, и пишем сразу e2e. Причина в том, что юниты проверяют реализацию, а с ИИ реализация не имеет значения, она меняется каждую генерацию. Смысл есть только в проверке поведения снаружи. И конечно, тест-кейсы для этого стоит вести в системе управления, а не хранить в разрозненных файлах.
Когда убираешь рутину, заодно появляется шанс перейти на следующий этап и уйти от старой привычки к новой. Это не то, что до ИИ никто не знал, все эти принципы тестирования существовали и раньше. Просто в текущих реалиях это уже договорённость: раз ИИ может быстро писать e2e, ограничение "дорого и долго" затирается. Классическая тестовая пирамида, где юнитов много, а e2e совсем чуть-чуть, отражала ограничения инструментов своего времени, когда e2e были медленными и дорогими в поддержке. Сейчас это ограничение снимается, и ромб подходит лучше, чем пирамида: юниты остаются основой, но доля e2e растёт, потому что инструменты для них стали быстрыми и дешёвыми, и держать их наверху пирамиды просто по привычке больше не обязательно.
#ai #tests