Есть тулза — генератор кода. На входе получает файл и опции для генерации в командной строке, на выходе — выдаёт файл.
Надо в ней поковыряться, но так, чтобы ничего не сломалось. Вариант — зашить входной и выходной файл в в виде массива char'ов в код и как-то запилить все тесты в одном сорцовом модуле — не прокатит — входной файл может подключать другие файлы, а делать затычку, эмулирующую файловую систему на массивах char'ов, и впиливать прослойку абстракции в уже существующий код желания нет.
Исходные данные для вызова утилиты — имя входного файла, имя выходного файла, и опции командной строки.
Есть эталонный генератор — зафиксированная последняя перед переделками рабочая версия. Нужно нужно для каждого входного кортежа вызвать эталонную версию, экспериментальную текущую версию, и сравнить выхлоп.
При сравнении выхлопа пустые строки, или строки только с пробелами — игнорировать (можно наверное перед сравнением прогонять тупо через фильтр, который их удалит). Оставшееся — сравнить.
Опять же — сравнивать по разному, в зависимости от настроек — либо игнорить изменения в пробелах, либо точно сравнивать.
Полного дифа не нужно, достаточно генерить ошибку на первом несоответствии.
Ну, и в комлексе — либо прогнать все тесты, даже если некоторые не прошли, и потом отрапортовать, сколько сфейлилось, либо остановится на первом же фейле.
Здравствуйте, Marty, Вы писали:
M>Есть тулза — генератор кода. На входе получает файл и опции для генерации в командной строке, на выходе — выдаёт файл. M> ... M>Чем бы таким всё это организовать?
Я бы взял Python + PyTest и делал тесты работая с генератором как с черным ящиком. То есть для начала я бы сгененрировал файлы для тех случаев, которые хочу контролировать, потом написал бы сравнения базируюсь на твоих входных правилах (игнорить изменения в пробелах и т.д.) ну и банально запускал бы новый генератор и сравнивал с выхлопом от старого.
Re: Регрессионные тесты для тулзы в отдельном exe - как организовать?
Здравствуйте, kaa.python, Вы писали:
KP>Я бы взял Python + PyTest и делал тесты работая с генератором как с черным ящиком. То есть для начала я бы сгененрировал файлы для тех случаев, которые хочу контролировать, потом написал бы сравнения базируюсь на твоих входных правилах (игнорить изменения в пробелах и т.д.) ну и банально запускал бы новый генератор и сравнивал с выхлопом от старого.
Ну, то есть опять самому писать
Я думал, может есть что-то готовое для такого случая, имхо задача конечно не слишком частая, но всё же довольно типовая.
А PyTest — для чего тут он, он чем-то облегчит жизнь?
Здравствуйте, Marty, Вы писали:
M>Ну, то есть опять самому писать
Ты хочешь получить классические регрессионные тесты. Я бы потратил 1-2 дня и сделал по-уму, нежели потом страдал. Но с другой стороны, я на таких решения много шишек набил и может быть тебе этот подход будет не столько просто и прямолинеен как мне
M>Я думал, может есть что-то готовое для такого случая, имхо задача конечно не слишком частая, но всё же довольно типовая.
Все случаи уникальные. Можно банально diff подключить, как vsb выше советует, но уровень гибкости будет оставлять желать лучшего.
M>А PyTest — для чего тут он, он чем-то облегчит жизнь?
Тем что ты не будешь сваливать всё в одну кучу, и сделаешь несколько разных тестов. Я так понял, есть разные флаги, разные входные данные. Регрессия может вылезти на любой из этих комбинаций и, обычно, проще заранее определить проблемные группы нежели потом гадать в какой из групп лезет ошибка и выискивать закономерности.
Здравствуйте, kaa.python, Вы писали:
M>>Ну, то есть опять самому писать
KP>Ты хочешь получить классические регрессионные тесты. Я бы потратил 1-2 дня и сделал по-уму, нежели потом страдал. Но с другой стороны, я на таких решения много шишек набил и может быть тебе этот подход будет не столько просто и прямолинеен как мне
Ну, на работе с меня уже ржут: я с коллегой решил обсудить этот вопрос, он мне тоже diff посоветовал заюзать. Я его спрашиваю — а diff блоки пустых строк умеет игнорировать? Коллега такой: "хм, не знаю. Вроде нет. Можешь свой diff написать ". Просто я довольно часто, по сравнению с другими, пишу подобные штуки сам, вместо попыток использовать какие-то готовые средства. Обычно получается лучше, чем у других, и потом мои решения начинают все использовать, с другой стороны, именно моего времени тратится больше, и собсно продакшена я часто вроде как меньше выдаю. С другой стороны, и народ и начальство пользу в этом видят, но постоянно меня подкалывают
Ну и пишу на C++, кстати. Во-первых — продакшн у нас на плюсах, и что-то наработанное в таких утилитках бывает что допиливается, и потом используется в других местах, и в продакшене тоже 2) На плюсах, тем более на современных, на самом деле писать не сильно больше, чем на каком-то питоне. Само собой, в тех случаях, когда нет варианта просто подтянуть какой-то готовый питоновский модуль.
M>>Я думал, может есть что-то готовое для такого случая, имхо задача конечно не слишком частая, но всё же довольно типовая.
KP>Все случаи уникальные. Можно банально diff подключить, как vsb выше советует, но уровень гибкости будет оставлять желать лучшего.
Да, вот это и смущает. Что наворочу на diff'е колхозу, потом оно ещё жирком обрастёт, а потом всё равно гибкости не хватит и захочется переписать заново, но уже много времени будет инвестировано попытки сделать на стандартных инструментах, и переписывать не захочется
M>>А PyTest — для чего тут он, он чем-то облегчит жизнь?
KP>Тем что ты не будешь сваливать всё в одну кучу, и сделаешь несколько разных тестов. Я так понял, есть разные флаги, разные входные данные. Регрессия может вылезти на любой из этих комбинаций и, обычно, проще заранее определить проблемные группы нежели потом гадать в какой из групп лезет ошибка и выискивать закономерности.
Хм. А что значит — сваливать в одну кучу? Если самому писать, я бы типа инишки написал, где описывались бы входные кортежы, и по ним бы проходил. Никакой кучи и без какого-либо PyTest'а
Здравствуйте, Marty, Вы писали:
M>Ну и пишу на C++, кстати. Во-первых — продакшн у нас на плюсах, и что-то наработанное в таких утилитках бывает что допиливается, и потом используется в других местах, и в продакшене тоже 2) На плюсах, тем более на современных, на самом деле писать не сильно больше, чем на каком-то питоне. Само собой, в тех случаях, когда нет варианта просто подтянуть какой-то готовый питоновский модуль.
Я бы однозначно не стал писать никаких интеграционных или регрессионных тестов на плюсах. Да, на первый взгляд это не сложно и можно. Но когда оно разрастется ты очень быстро упрешься в то, что одна строка на Python равна 3-5 на плюсах в очень многих случаях. Таки проще один раз выучить Python. Я на нем вообще ничего кроме тестов не пишу, но оно того стоит.
Мне всегда важно что бы можно было легко работу передать новичку какому-то, и при таком подходе ты всегда можешь какого-нибудь интерна посадить дописывать и не бояться что он всё разломает. В командной работе это крайне важно, но, само собой, у тебя могут быть другие условия.
M>Хм. А что значит — сваливать в одну кучу? Если самому писать, я бы типа инишки написал, где описывались бы входные кортежы, и по ним бы проходил. Никакой кучи и без какого-либо PyTest'а
В PyTest у тебя будет несколько тестов на разные ситуации. Сразу будет видно что и почему отвалилось, что очень полезно при интеграции с CI/CD.
Re[6]: Регрессионные тесты для тулзы в отдельном exe - как о
Здравствуйте, kaa.python, Вы писали:
M>>Ну и пишу на C++, кстати. Во-первых — продакшн у нас на плюсах, и что-то наработанное в таких утилитках бывает что допиливается, и потом используется в других местах, и в продакшене тоже 2) На плюсах, тем более на современных, на самом деле писать не сильно больше, чем на каком-то питоне. Само собой, в тех случаях, когда нет варианта просто подтянуть какой-то готовый питоновский модуль.
KP>Я бы однозначно не стал писать никаких интеграционных или регрессионных тестов на плюсах. Да, на первый взгляд это не сложно и можно. Но когда оно разрастется ты очень быстро упрешься в то, что одна строка на Python равна 3-5 на плюсах в очень многих случаях. Таки проще один раз выучить Python. Я на нем вообще ничего кроме тестов не пишу, но оно того стоит.
Позволю себе с тобой не согласиться.
1) Питон таки я худо бедно знаю, а что подзабыл — вспомнить не большая проблема
2) То, что на питоне пишется в одну строчку, а на плюсах — в четыре, это — можно вынести в отдельную функцию и написать её понятно, хоть в 10, хоть в 20 строк, дав ей вразумительное имя.
3) Чем жирнее становится питоновский скрипт, тем меньше в нём становится чего-либо понятно.
В голову приходит perl, где можно было писать write only короткие конструкции с использованием переменных по умолчанию и прочего говна. Для того, кто знал перл очень хорошо — это было нетрудно, а для того, кто в перл заглядывал лишь иногда — это было адом. Так что уж лучше 5 строчек, где всё разложено по полочкам, чем одна, вида "хз как оно вообще работает"
Питон неплох в качестве продвинутого bash'а для небольших скриптов, но после тыщи строк он уже становится мало контролируем и понимаем
KP>Мне всегда важно что бы можно было легко работу передать новичку какому-то, и при таком подходе ты всегда можешь какого-нибудь интерна посадить дописывать и не бояться что он всё разломает. В командной работе это крайне важно, но, само собой, у тебя могут быть другие условия.
а это —
4) У нас все — плюсовики, других не держим и не берём. Все "интерны" более или менее знают C++, но не факт, что знают питон.
А питоновское разломать — имхо, гораздо проще, чем плюсовое. В таких тулзах если на C++ обычно мегашаблонное александреску не используется, а просто "C с классами" и "C с шаблонами"
M>>Хм. А что значит — сваливать в одну кучу? Если самому писать, я бы типа инишки написал, где описывались бы входные кортежы, и по ним бы проходил. Никакой кучи и без какого-либо PyTest'а
KP>В PyTest у тебя будет несколько тестов на разные ситуации. Сразу будет видно что и почему отвалилось, что очень полезно при интеграции с CI/CD.
Ну может мне наверно надо таки глянуть, что за зверь этот PyTest
Но пока так и не понятно, чем бы он упростил жизнь в данной ситуации.
Может, есть какой-нибудь пример практики, похожий чем-то на мой случай?
Здравствуйте, Marty, Вы писали:
M>Ну, на работе с меня уже ржут: я с коллегой решил обсудить этот вопрос, он мне тоже diff посоветовал заюзать. Я его спрашиваю — а diff блоки пустых строк умеет игнорировать?
-Z, --ignore-trailing-space
ignore white space at line end
-b, --ignore-space-change
ignore changes in the amount of white space
-w, --ignore-all-space
ignore all white space
-B, --ignore-blank-lines
ignore changes where lines are all blank
Я этими опциями не пользовался и детально не знаю, как они работают. Но вроде что-то такое есть. Ещё можно перед передачей файла в diff сделать ему препроцессинг и убрать что-нибудь, например повторяющиеся пустые строки. Это тоже одна строчка на баше.
Хз, имхо, лучше потратить 20 минут, сделать скрипт на баше и забыть, чем тратить минимум день на C++ или Python.
Здравствуйте, vsb, Вы писали:
vsb>Я этими опциями не пользовался и детально не знаю, как они работают. Но вроде что-то такое есть. Ещё можно перед передачей файла в diff сделать ему препроцессинг и убрать что-нибудь, например повторяющиеся пустые строки. Это тоже одна строчка на баше.
vsb>Хз, имхо, лучше потратить 20 минут, сделать скрипт на баше и забыть, чем тратить минимум день на C++ или Python.
Что-то здравое в этой идее есть, не могу поспорить
Пока обмозговывал, родилась ещё одна хотелка — сравнение без учёта регистра (для латинницы)
Здравствуйте, kaa.python, Вы писали:
M>>Кроме шуток, это реальный совет (с учетом озвученных мной реалий), или ты просто отмазался, устав со мной спорить?
KP>Мне не платят за спор с тобой, и смысла тебя переубеждать нет.
Здравствуйте, Marty, Вы писали:
M>Я его спрашиваю — а diff блоки пустых строк умеет игнорировать? Коллега такой: "хм, не знаю. Вроде нет. Можешь свой diff написать ".
