Python функциональные тесты

и как, «helloword.py» уже стабилен ?

py.test, топик не читал.

Хелоуворлд скорее main.cpp. И он как бэ стабилен, но таки кейсов реально дохрена.

Ну на лоре я другого первого ответа и не ожидал.

Ну даже он концептуально показался милее стандартной хрени.

Однако хотелось бы услышать про киллер фичи, инсайдерскую инфу. Типа что бы было чем аргументировать манагеру, кроме «как то оно не удобно нифига выходит».

Плюсую pytest. Ничего круче для питона пока не придумали.

fixtures — самая главная киллер фича, ради которой стоит переходить, я считаю.

В стандартном unittest ЕМНИП, нельзя просканировать пакет и запустить тесты, нужно писать свой костыль. В либах типа nose и pytest это из коробки и даже настраивается. Ещё есть куча всяких плюшек вроде drop into pdb при фейле, отправка лога на pastebin, запуск конкретной группы тестов, параметризация (запуск одного и того же теста с разным набором данных).

А ещё ничто не мешает использовать pytest вместе с unittest.

это всё можно было сделать повеселее

doctest?

фикстуры есть и в unittest. Хотя в pytest, как они оформленны, мне тоже показалось интереснее, особенно то, что их можно подмешивать в тест в отличии от unittest.

Ок, крутые фикстуры и параметризованные запуски, это уже что то, спасибо.

Код - не на питоне. Тесты функциональные, для высокоуровневых требований.

Кейсы типа: если 5 клиентов кинули на сеть 100 мессаг в определённом порядке, 3ех из них надо отрубить и написать в лог что они сволочи, а остальным двум послать ещё 100 мессаг.

Было бы круто вообще какое нибудь bdd прикрутить, но чет я пока не уверен что осилю и убедю кого то ещё осилить. Плюс там не фига не рест или вебморды поэтому придётся много велосипедить и докручивать скорее всего.

Понятно что rtfm и надо пробовать, но таки спрошу.

Можно ли в py.test/nose запросить выполнить тесты из двух подпапок/пакетов?

Можно ли делать составные запросы уровня хотя бы - запустить «это_вел*колепие» и не пускать «это_г*в?о;и_это_*_тоже»?

Можно ли тестам давать теги(что бы потом указать их в запросе на запуск)? Можно ли строить запрос по запуску тестов на основе используемых ими фикстур?

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

Ну и да, понятно, что можно таки всё, и к unittest это прикрутить, чем я итеративно и успешно промышляю, вопрос в том - насколько это сложно:)

Типа что бы было чем аргументировать манагеру, кроме «как то оно не удобно нифига выходит».

Так может стоит плясать от этого? Определить чёткий список требований и решить, что лучше: писать свой велосипед или взять nose/pytest.

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

Таки RTFM.

http://pytest.org/latest/example/markers.html

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

В nose это работает и так. Вообще это фича unittest, если не ошибаюсь. А вот pytest плевал на всё это и выводит как ему хочется. Но ничто не мешает найти/написать плагин.