LINUX.ORG.RU

Python unittest расширение для передачи аргументов

 ,


0

3

Вообщем питоновский unittest штука бодрая, и что важно - есть из коробки, но охота передавать параметры через argv. Однако, не стали афторы эту возможность запиливать, аргументируя сиё непотребство маловразумительными плачами на тему «ай яй яй, юнит тесты должны сами себя сетапить и очищать».

Как бэ по поводу юнит-тестов и хрен бы с ним, но таки можно же и функциональные вполне себе пилить.

Запилил костыль на скорую руку, т.к. сходу ничего умного не нагуглилось.

Мэй би кто встречал нормальную проксю, для аргументов коммандной строки сабжа, дабы можно было мне не заниматься костылеписанием, а заюзать нечто готовое?

★★★★★
Ответ на: комментарий от anonymous

Гуглить умею, даже мой костыль, имхо, симпатишней, чем вручную тесты пускать, или завязываться на порядок следования аргументов, тем более есть discover и аргументы самого unittest.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от holuiitipun

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

pon4ik ★★★★★
() автор топика

Мне тоже интересно, кто-нибудь что-нибудь готовое знает...

я сейчас так делаю - основной модуль с main'ом парсит command-line, готовит «environment» объект, импортит модуль с тестами, сетапит тесты «модуль.setup(environment)» и прогоняет «модуль.run()»

MadMax
()
Ответ на: комментарий от pon4ik

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

Очень странная мысль. Как раз параметры окружения или переменные, можно хранить в файле, в конфигах, в гите и как положено. Что собственно является ключевым для воспроизводимости. А копипаст команды, это может быть использовано в разработке, но совершенно не подходит для долгосрочного использования.

Ну и VAR=smth command никто не отменял.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Угу особенно бодро такой коммандлайн работает под офтопиком :)

А хранить в конфигах, под контролем версий, то к чему в всех разные пути например - тоже не ахти подход.

Заставить всех класть в одинаковые места? Сколько кусочков коричневого счастья прилетит в мой адресс?

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

А хранить в конфигах, под контролем версий, то к чему в всех разные пути например - тоже не ахти подход.

Либо относительные пути, либо отдельный файл с локальными настройками типа ~/.mysettings

true_admin ★★★★★
()
Ответ на: комментарий от pon4ik

А хранить в конфигах, под контролем версий, то к чему в всех разные пути например - тоже не ахти подход.

Можно хранить conf.default, а каждый разработчик у себя из него делает conf.

holuiitipun
()
Ответ на: комментарий от true_admin

Звучит как костыль на пустом месте, по крайней мере для меня.

Чего ради - если основных параметров немного.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от holuiitipun

Можно так же предложить каждому разработчику скопировать скрипт запуска и поправить его, учитывая стиль питона это примерно соразмерные решения :)

pon4ik ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.