То есть шаги всегда одни и те же: вызываем действие, сравниваем результат.

еще один познал дзен

Почему бы тогда не пользоваться тем же nosetest'ом не только для модульного тестирования, но и в качестве пускалки python'овских сценариев запускающих нагрузочные тесты

ога, а потом самому писать сценарии увеличения нагрузки, распараллеливать разные сценарии, собирать метрики, etc. действительно, почему бы и нет, времени же у всех вагон и тележка

функциональные тесты, Sikuli, прочее.

особенно это актуально для проверки, например, насыщенного жабаскриптом говна в браузере. у нас же в рабочем дне 48 часов, а в сутках все 128, напишем собственную библиотеку, зачем нам webdriver

В нашем распоряжении сразу оказывается язык с большой библиотекой, поддержка на уровне платформы (framework'а) таких вещей как фикстуры, сценарии запускаемые перед тестом, после теста, запуск из командной строки, возможность легко привязать к системе контроля версий.

то есть с тем, что есть в абсолютно любом нормальном тестовом фреймворке

Зачем тогда городить FitNesse, который сам себе standalone вики с возможностью нажать кнопочку test и запустить примерно такие же скрипты, и ответ увидеть не в командной строке, а в виде зелёных прямоугольничков в браузере. Зачем всё это?

затем, чтобы этим занимался не разработчик, и даже не мидл qa, а джуниор или вообще продукт овнер. внезапно, да

Дзен овнера

ога, а потом самому писать сценарии увеличения нагрузки, распараллеливать разные сценарии, собирать метрики, etc. действительно, почему бы и нет, времени же у всех вагон и тележка

Зачем это всё писать самому? Просто вызовы соответствующих программ могуть быть в python'овском сценарии.

особенно это актуально для проверки, например, насыщенного жабаскриптом говна в браузере. у нас же в рабочем дне 48 часов, а в сутках все 128, напишем собственную библиотеку, зачем нам webdriver

Что это за бред вы написали? Запуск Webdriver'а и прочие сценарии с запуском Firefox'ов и прочих Selenium'ов я уже не смогу обернуть в python'овский сценарий? Что это за автоматизация тестирования, если я не могу запустить тест из командной строки? Вы что-то имеете против Sikuli или функционального тестирования?

то есть с тем, что есть в абсолютно любом нормальном тестовом фреймворке

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

затем, чтобы этим занимался не разработчик, и даже не мидл qa, а джуниор или вообще продукт овнер. внезапно, да

А вот это внезапно. Джуниор или вообще продукт овнер пишет в вики: нажимаешь |B| и текст выводится полужирным начертанием. А кто будет писать этот тест? FitNesse сам прочитает мысли овнера и сделает тест, или это специалист напишет запускатор продукта, нажиматор в нём |B|, проверку того что текст выводится с нужным начертанием? Потом овнер нажмёт в FitNesse кнопку Test, запустит проверочный сценарий и порадуется какой замечательный тест от сделал.

Зачем это всё писать самому? Просто вызовы соответствующих программ могуть быть в python'овском сценарии.

каких соответствующих? давай с конкретными примерами, раз уж решил на коленке сделать замену, к примеру, jmeter'a

Запуск Webdriver'а и прочие сценарии с запуском Firefox'ов и прочих Selenium'ов я уже не смогу обернуть в python'овский сценарий?

запросто можно. но при чем тут nosetests?

Что это за автоматизация тестирования, если я не могу запустить тест из командной строки?

Что это за бред вы написали?

да хоть из cmd.exe, какая разница?

Вы что-то имеете против Sikuli

кроме ада, в который превращается поддержка тестов sikuli на более-менее крупном проекте? не, ничего

или функционального тестирования?

wat

Так зачем их так много, если они все делают одно и то же: выполнил-сравнил.

так зачем так много языков програмирования, если все они делают одно и то же: написал выполнил.

И почему одни для модульного, а другие для приёмочного тестирования?

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

Джуниор или вообще продукт овнер пишет в вики: нажимаешь |B| и текст выводится полужирным начертанием.

ну апще-то джуниор тесты пишет редко, он их выполняет

А кто будет писать этот тест? FitNesse сам прочитает мысли овнера и сделает тест, или это специалист напишет запускатор продукта, нажиматор в нём |B|, проверку того что текст выводится с нужным начертанием? Потом овнер нажмёт в FitNesse кнопку Test, запустит проверочный сценарий и порадуется какой замечательный тест от сделал.

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

Рай/Ад (нужное подчеркнуть)

каких соответствующих? давай с конкретными примерами, раз уж решил на коленке сделать замену, к примеру, jmeter'a

Зачем мне писать замену jmeter'а, если я могу вызывать его из python'овского сценария? nose просто обёртка-запускатор. Раскладываю тесты по файлам, файлы по папочкам, хочу запускаю все, хочу только те что в некоторой директории, хочу объединяю тесты со сходными стартовыми условиями в один класс, не хочу — не объединяю.

запросто можно. но при чем тут nosetests?

Ну, как-то же их надо запускать. FitNesse будет запускать 100 тестов лучше чем nose? Скорее всего примерно так же. Можно из сценариев оболочки запускать. Просто nose мне кажется капельку удобнее.

да хоть из cmd.exe, какая разница?

Вот и я спрашиваю, какая разница? Зачем мне nose и FitNesse, если я могу обойтись одним только nose? В моём случае нет овнера который самостоятельно будет писать требования в вики. В моём случае требования могут быть спущены сверху в виде бумаги с печатью, а nose для проверки выполнения требований может запустить мой технически грамотный начальник. И ему тоже удобнее и понятнее если тесты запускаются из командной строки, если запуск тестов привязан к hook'ам Subversion'а и почтовым уведомлениям. А отчитываться о выполнении требований перед высшим руководством он всё равно будет голосовым ртом лица головы.

кроме ада, в который превращается поддержка тестов sikuli на более-менее крупном проекте? не, ничего

А как вы предлагаете тестировать GUI (не web)? Я весь внимание, эта тема мне действительно интересна.

wat

WAT что?

так зачем так много языков програмирования, если все они делают одно и то же: написал выполнил.

Да, но я вижу различия в подходах и области применимости C и Python'а. А вот с инструментами тестирования мне пока не удалось разглядеть значимых отличий.

ну апще-то джуниор тесты пишет редко, он их выполняет

Выполнять тест должна ЭВМ.

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

Да, но поддержку действий всё равно писать специалисту, и тут нет большой разницы будет ли это Java или Python. А если уж так хочется писать тесты и поддерживалки действий на Python, а результат задавать из веба, то можно написать небольшое вебовое приложение, которое будет брать из вики условие и проверять его nose'ом. Назвать это NEAT (Nose Enterprise Acceptance Testing). PROFIT.

Betterspecs

Набрёл на занимательный ресурс:

http://betterspecs.org/ru

До того относился к BDD и RSpec скептически, не понимал чем это отличается от docstring'ов в nosetest'ах. Теперь всё ещё отношусь скептически, но вижу в RSpec'ах некоторую красоту, хотя и сомнительную. Суть хороших docstring'ов и spec'ов в том, что в них должно быть написано какое-то позитивное утверждение проверяемое в тесте. Непонятно написать docstring можно ровно с таким же успехом как и spec, написать плохой тест можно одинаково в обоих случаях. Разница в том, что docstring пишет на человеческом языке, а spec пишется на смеси spec'а, Ruby и человеческого, это позволяет сделать описание теста короче, но понятнее ли, особенно для постороннего человека.

Это были просто мысли вслух. Не стоит ли вместо nose'а взять RSpec.

Зачем мне писать замену jmeter'а, если я могу вызывать его из python'овского сценария? nose просто обёртка-запускатор. Раскладываю тесты по файлам, файлы по папочкам, хочу запускаю все, хочу только те что в некоторой директории, хочу объединяю тесты со сходными стартовыми условиями в один класс, не хочу — не объединяю.

и как часто ты собираешься пускать jmeter? очередное ноу-хау - нагрузочное тестирование каждый день? jmeter - полностью готовый инструмент для выполнения вполне конкретной задачи: сдизайнить и запустить нагрузочные тесты. нахрена его оборачивать в какой-то еще фреймворк?

Вот и я спрашиваю, какая разница? Зачем мне nose и FitNesse, если я могу обойтись одним только nose? В моём случае нет овнера который самостоятельно будет писать требования в вики. В моём случае требования могут быть спущены сверху в виде бумаги с печатью, а nose для проверки выполнения требований может запустить мой технически грамотный начальник. И ему тоже удобнее и понятнее если тесты запускаются из командной строки, если запуск тестов привязан к hook'ам Subversion'а и почтовым уведомлениям. А отчитываться о выполнении требований перед высшим руководством он всё равно будет голосовым ртом лица головы.

а я откуа знаю зачем тебе nose и FitNesse, кроме того, что ты сам себе придумал? поправь меня если я ошибаюсь, но ты работаешь в «команде» из одного себя, и сам себе разработчик, тестировщик и бизнес-аналитик.

А как вы предлагаете тестировать GUI (не web)? Я весь внимание, эта тема мне действительно интересна.

java - abbot, net/winforms - white, linux - dogtail... даже powerbuilder'овские приложения виндовым UIAutomation тестируются на ура, без мудохания со скриншотами

WAT что?

wat то, что пассаж о том, что я что-то имею против функционального тестирования мне непонятен

Да, но я вижу различия в подходах и области применимости C и Python'а. А вот с инструментами тестирования мне пока не удалось разглядеть значимых отличий.

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

Выполнять тест должна ЭВМ.

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

можно написать небольшое вебовое приложение, которое будет брать из вики условие и проверять его nose'ом. Назвать это NEAT (Nose Enterprise Acceptance Testing). PROFIT.

PROFIT это если вам за количество строк кода платят, ну или там за количество проведенного времени. А если у вас сроки, бюджет, рейты и эстимейты - это не профит а факап. Потому что тратить время на написание велосипеда при наличии кучи аналогов - идиотизм, который заказчик вряд ли оценит

Задом наперёд всё наоборот

и как часто ты собираешься пускать jmeter? очередное ноу-хау - нагрузочное тестирование каждый день? jmeter - полностью готовый инструмент для выполнения вполне конкретной задачи: сдизайнить и запустить нагрузочные тесты. нахрена его оборачивать в какой-то еще фреймворк?

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

поправь меня если я ошибаюсь, но ты работаешь в «команде» из одного себя, и сам себе разработчик, тестировщик и бизнес-аналитик.

Поправляю, ошибаетесь, в команде я лишь винтик, помимо меня есть и разработчики, и тестировщики и аналитики.

java - abbot, net/winforms - white, linux - dogtail... даже powerbuilder'овские приложения виндовым UIAutomation тестируются на ура, без мудохания со скриншотами

Подход Sikuli хорош тем, что анализирует ровно то что увидел бы человек, а не то что выдаёт машина каким-нибудь API. Можете ли вы ещё что-нибудь сказать о LDTP в сравнении с Dogtail? По описанию очень похожи.

wat то, что пассаж о том, что я что-то имею против функционального тестирования мне непонятен

Зачем тогда цитировали?

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

Всё приходит с опытом. Никто кроме твердолобых фанатиков не будеть совать солидол туда, где достаточно шерсти, и наоборот, потому что одна и та же задача разными инструментами выполняется за разное время и с разными усилиями. Вы пытаетесь убедить меня, что я противопоставляю junit selenium'у?

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

Вот теперь и я посмотрю, пожелайте мне удачи.

PROFIT это если вам за количество строк кода платят, ну или там за количество проведенного времени. А если у вас сроки, бюджет, рейты и эстимейты - это не профит а факап. Потому что тратить время на написание велосипеда при наличии кучи аналогов - идиотизм, который заказчик вряд ли оценит

Про «сарказм» слыхали?

И вдогонку, для разжигания срача нашей замечательной и плодотворной дискуссии. Вы заметили, что nose и RSpec очень похожи? Я между ними не вижу почти никакой разницы. При этом одно позиционируется для модульного тестирования (самый низкий уровень), а другое для приёмочного (самый высокий уровень). Парадокс?

Про команду: если в команде есть qa - мне категорически не понятно, почему у вас постоянно возникают нубопосты о тестированию.
Про sikuli - задача тестирования gui - проверять кейсы через графический интерфейс, а не проверять внешний вид. То есть задача фреймворка - нажимать кнопочки, только и всего. Sikuli тоже нажимает кнопочки, но делает это через костыли. Ldtp, dogtail etc(да, все такие фреймворки отличаются только в деталях, выбор конкретного - обычно личные предпочтения qa, как и выбор selenium/wati(j/n/r)) - делают это без костылей, и тесты на них гораздо проще поддерживать.
Про junit, selenium и инструмент - я наблюдаю у вас самый обычный синдром утенка, мол есть крутой инструмент, так давайте все делать им. Глупо, в чем вы убедитесь, если попробуете это организовать: вместо стройной системы фреймворк очень быстро станет похож на даунхил с велосипедом и костылями. Нет ничего плохого в том, чтобы разделить тестовые фреймворки по уровням.
Про приемочное тестирование - вообще я недавно тут с одним теоретиком обсуждал уже это: в модных книжках по agile в последнее время форсят приемочное тестирование как комбинацию функционального и регрессионного, отсюда и попытки изобрести фреймворки для его автоматизации. Которые по сути bdd'шный фреймворк для функционального тестирования, только называется фреймворком для приемочного тестирования. Так-то приемочное тестирование выполняется редко, сценарии зависят от желания левой пятки заказчика, поэтому смысла его автоматизировать нет.

Спасибо за объяснение

Спасибо за объяснение и советы.

Напиши это в виде карты памяти (freemind неплох)

Больше треша!

make! Мне нужен make! Или rake, или waf, или scons. Пускатор такой пускатор. Пускатору не обязательно быть платформой для тестирования.

водка медленно разрушает организм

ШТА?