В итоге выкинул код относительно тестов перцентилей который мучал и не хотел писать, решил пойти другим путём. Сделаю возможность написания не юнит-тестов на отдельные wasm-функции (это и автор модуля может сделать на своей стороне, мои тесты скорее нужны чтобы убедиться, что wasm соответствует моим биндингам), а интеграционных тестов, которые смогут делать с базой всё что захотят, просить запустить определённые в конфиге трансформации, читать получившиеся коллекции и смотреть, что там всё как надо.
Таким образом оно будет не только тестировать корректность wasm'а, но и корректность самих трансформаций и работу базы. Такие тесты всё равно когда-нибудь нужно будет писать (у меня есть тесты на базу, которые её запускают целиком и проверяют что методы работают как нужно, есть отдельные тесты на прогон транформаций (но без запущенной базы), а вот будут и полные, которые прогоняют трансформации на живой базе). И тут сильно меньше работы получается.
Всё что будет нужно — писать human-readable функции для коллекций (они пригодятся в будущем, когда буду UI делать, чтобы глазами на коллекцию смотреть) и... всё. Тесты эти будут писаться wasm-функцией, в итоге она сможет переиспользовать механизм запросов который будет доступен из трансформаций, единственное что нужно сделать кроме — дополнительную функцию запуска трансформаций, но это тривиально. И не нужно писать human-readable функций для промежуточных типов данных, они будут прятаться внутри вычислений и проверяться только итоговый выход (и его тоже проще будет проверять, т.к. не нужно будет сериализировать-десериализировать их туда-сюда, а просто сравнить либо побайтово, либо структурно, смотря что там за значения лежат в коллекциях.
Не уверен что найду сильно много вечеров/выходных чтобы плотно этим всем заняться, я тут ещё и Path of Exile 2 скачал, плюс новый DLC Factorio всё ещё не пройден, но по чуть-чуть постараюсь возвращаться.
Запишу себе тут план, чтобы видеть путь и свет в конце туннеля:
◾️ Написать flatbuffers-схемы запросов которые могут понадобиться для тестов (старт поколения, запись значений в коллекцию, коммит поколения, чтение коллекции, по сути и всё, наверное и взятие диффа между поколениями не нужно пока)
◾️ Реализовать в cli команду инициализации базы согласно определённым в конфиге коллекциям (странно, я думал она была)
◾️ Дополнить парсинг конфига, при виде специального типа тестов создавать временный каталог, стартовать новую базу в нём, создавать коллекции
◾️ Сделать новый wasm-биндинг запуска трансформации по имени из конфига (такая команда в cli уже есть, нужно просто вызвать нужную функцию)
◾️ Написать самих тестов, которые создадут новые записи в изначальной коллекции, попросят запустить агрегацию, прочитают итоговую, сравнят с ожидаемыми значениями, промутируют коллекцию, снова запустят, посмотрят что обработка диффа тоже работает
◾️ Тесты ожидаемо упадут, т.к. у меня не реализована пока сама логика этих агрегаций, реализовать их
◾️ Всё ещё будут падать, т.к. не реализован механизм запросов, реализовать их (нужно будет помимо json-апи поддержать и flatbuffers)
◾️ Должно будет сойтись
Ну а когда всё-таки осилим это, сделаю cli-команд для чтения коллекций и перейду к реализации взаимодействия с телеграм-ботами по схеме
https://t.me/alexandersmind/521 , т.к. у меня помер антиспам-бот (форк Shieldy с фичей кастомных вопросов вместо каптчи) и не особо хочу его чинить (там что-то мутное с нарушением уникальных ключей в монге, я так и не понял). Реализую его новую версию, выкинув все фичи кроме совсем необходимых, запущу, посмотрю, нужен ли он ещё кому-нибудь. Он будет генерировать какое-то количество метрик (ничего криминального, никаких сообщений не логирую, только количества, тайминги), которые пообрабатываю всей этой ерундовиной. Только wasm попробую не на расте писать, хочу Zig ещё попробовать, а воркер на Go бахну, давно на него не смотрел и кажется подойдёт для того чтобы без конца ходить в апишку за изменениями, парсить и класть задачи в коллекции, которые затем будут обрабатываться трансформациями.
#diffbelt
