ImageSorcery 05 - автотесты; просто покажи ему пример
Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.
ImageSorcery 01 - Как я свой open source вайбкодил
ImageSorcery 02 - Превращение ImageWizard в ImageSorcery
ImageSorcery 03 - шаг за шагом: PoC, Initial commit
ImageSorcery 04 - README.MDВ прошлой серии мы поговорили про важность README для вайбкодинга. В этой не менее важная тема - автотесты.
Не поленюсь ещё раз всем напомнить что я джун в python, а это значит что даже с самым качественным README я не могу на 100% утверждать что понимаю как работает проект написанный целиком ИИ. Из-за чего я не могу полностью доверять ИИ, когда он его меняет. Это приводит нас к выводу о необходимости автотестов. Не только как к способу повысить качество, надёжность и прочие пафосные метрики. А как к единственно возможному способу реализовать, а в дальнейшем развивать проект через вайбкодинг.
Вперёд вайбкодить автотесты!
Сказано - сделано. Cline + Gemini flash:
“Прочитай @README.MD для понимания проекта. Напиши автотест, который будут проверять наш единственный hello world tool.”
Тест на pytest готов ваншотом. Он passed 🎉! Казалось бы, пора открывать шампанское. Но как говорится: доверяй, но проверяй. На проверку это оказался юнит тест. Он конечно технически проверяет что функция написания в файле hello_world.py работает. Но он не проверяет, объявляет ли такой tool мой MCP сервер, возможно ли вызвать этот tool, вернёт ли он значение в ожидаемом MCP клиентом формате.
Я совершил классическую для вайбкодера ошибку - поставил задачу не достаточно чётко.
Ок, откатываем все изменения (благо я с самого начала завёл git - обязательную вещь для вайбкодинга и обычной разработки) и промптим заново:
“Прочитай @README.MD для понимания проекта. Напиши e2e автотест, который будут проверять наш единственный hello world tool подключаясь к этому MCP серверу как MCP клиент”
Я знал что ImageSorcery в своём зачаточном виде работает через stdio - стандартный протокол для MCP серверов работающих локально. Это значит что его можно запустить как подпроцесс и, отправив в него нужные данные, получить ответ.
Правда это не звучит как простая типовая задача? Вот и я так подумал. Вот и Gemini Flash так подумал. И облажался. И Pro облажался. И o3-mini. И Sonnet.
Ну мне не привыкать к тому как ИИ лажают. Взял дело в свои руки. И тоже облажался 🤦. Целый день я потратил в тщетных попытках отправить по stdio хоть что-то и получить хоть какой-то ответ. А разгадка одна - безблагодатность нужно звать батю. Благо такой батя в виде коллеги python senior software developer у меня имелся. Я пришёл к нему в слезах со словами что в попытках покрыть автотестами MCP сервер работающий по stdio что только не испробовал и на этом мои полномочия всё, закончились. Он, взглянув одним глазом на проект и ситуацию в целом сказал: “Просто покажи своей ИИшке пример MCP сервера покрытого автотестами. Таких что ли нет на GitHub? У нас в python фиг найдёшь задачу, которую до тебя ещё не решили и не обернули в удобную либу.”
А официальная документация тем временем имела ссылку на GitHub с официальными примерами. А в этих примерах используется либа FastMCP. Я скормил пример Cline - отличный результат ваншотом. Попросил переписать всю реализацию на FastMCP - так же ваншот, и тесты не упали. Попросил актуализировать в связи изменениями README. git commit.
Этот шаг готов ✅
Я уже точно не помню, но где-то в процессе (до или после тестов) добавил ещё и линтер ruff. Но это было так просто что я даже не запомнил где и как это случилось. Линтер нужен, чтобы держать код в едином стиле. Полезно для вайбкодинга и в целом.
Теперь я готов приступать к реализации MVP.
Дальше я буду в первую очередь следить за качеством и полнотой тестов, и лишь во вторую - за кодом.
Но это уже в следующий серии.