Сообщений в теме: 51

[LeshaL]

Может у нас разное представление о том, что такое "компилируемые языки" и что такое "скриптовые языки"?

Ок, согласен - компилируемые и интерпретируемые.

Если под скриптовыми подразумеваются языки с наличием интерпретатора, то BeanShell превращает Java в скриптовый язык.

На мой взгляд джаваскрипт даже удобнее чем биншелл. В таком варианте, я согласен на джаву, у меня даже есть один инструмент, который реализован на связке ANT + JS + Java. Но хочу его переделать на rake.

Теперь ответ на вопрос чем же они неудобны. Вот у меня есть один инструмент написанный на джаве. Он состит из некоторого кол-ва классов (пусть 10). Чтобы его распространять для работы, всё это добро упаковано в jar и положено в некое место, где лежат всякие сторонние тулы. Сырцы в репозитории. Чтобы с этим удобно работать было - нужно IDE. Любое изменение требует запуска шага, который перепаковывает jar и еще шага, по копированию нового джара в старое место.

Теперь скрипт (на интерпретируемом языке). Документ (он же запускаемый файл) лежит в мастер-репозитории, доступном по NFS и запускается с любого компа прям оттуда. Всё. Все знают это одно постоянное место и работают с ним. Если нужно что-то поменять - Far или какой-нить joe - меняем в своем дочернем репозитории, убеждаемся, что все работает - закидываем в мастер-реозиторий (check-in) и у всех появляется новая версия естественным путем. Уходит куча ненужных шагов, а остаются шаги, которые в варианте с джавой все-равно тоже надо делать.

Теперь "сырец и документация и запускаемый файл". Если с тулом имеет дело не его автор, то могут возникнуть некоторые сложност или непонятки как с ним быть или почему не работает. И человеку нужно всего-лишь посмотреть в сам скрипт и понять, что он делает не так или где там ошибка. В конце-концов взять и сделать свой альтернативный вариант или исправить ошибку в скрипте, если есть. Ему не надо думать, а где сырцы лежат. И документацию не надо искать отдельно (она у нас есть, если честно и для скриптов тоже, но зараза устаревает постоянно).

[stmark]

Теперь ответ на вопрос чем же они неудобны. Вот у меня есть один инструмент написанный на джаве. Он состит из некоторого кол-ва классов (пусть 10). Чтобы его распространять для работы, всё это добро упаковано в jar и положено в некое место, где лежат всякие сторонние тулы. Сырцы в репозитории. Чтобы с этим удобно работать было - нужно IDE. Любое изменение требует запуска шага, который перепаковывает jar и еще шага, по копированию нового джара в старое место.

Теперь скрипт (на интерпретируемом языке). Документ (он же запускаемый файл) лежит в мастер-репозитории, доступном по NFS и запускается с любого компа прям оттуда. Всё. Все знают это одно постоянное место и работают с ним. Если нужно что-то поменять - Far или какой-нить joe - меняем в своем дочернем репозитории, убеждаемся, что все работает - закидываем в мастер-реозиторий (check-in) и у всех появляется новая версия естественным путем. Уходит куча ненужных шагов, а остаются шаги, которые в варианте с джавой все-равно тоже надо делать.

Теперь "сырец и документация и запускаемый файл". Если с тулом имеет дело не его автор, то могут возникнуть некоторые сложност или непонятки как с ним быть или почему не работает. И человеку нужно всего-лишь посмотреть в сам скрипт и понять, что он делает не так или где там ошибка. В конце-концов взять и сделать свой альтернативный вариант или исправить ошибку в скрипте, если есть. Ему не надо думать, а где сырцы лежат. И документацию не надо искать отдельно (она у нас есть, если честно и для скриптов тоже, но зараза устаревает постоянно).

1. Про Java мало что могу сказать, в моем случае C# и студия. Всё что нужно, запустить студию и кликнуть "прогнать в NUnit", всё. Нужно что-то менять - куча инструментов и удобная навигация по коду. Я прямо в коде даже метаданные храню, ибо удобство работы возрастает в разы по сравнению с редактированием текстовых файлов.
2. Про документацию не понял, что за документация такая на автотесты\фреймворк, которые нельзя хранить прямо в коде?

[LeshaL]

1. Про Java мало что могу сказать, в моем случае C# и студия. Всё что нужно, запустить студию и кликнуть "прогнать в NUnit", всё. Нужно что-то менять - куча инструментов и удобная навигация по коду. Я прямо в коде даже метаданные храню, ибо удобство работы возрастает в разы по сравнению с редактированием текстовых файлов.

Понял, что смущает.
Когда-то, когда продукт над которым я работал был плагином к визуал студии, то конечно, я писал на C# тесты, которые использовали API продукта, написанного на C#-же. И писал я их в студии и были эти тесты addon-ом для студии. Это ок. А когда что-то было сделано на базе еклипса, то я писал какие-то тесты на джаве. Не вопрос.
Просто мы о разной автоматизации говорим. Я говорю о целом зоопарке различных скриптов, осуществляющих статические проверки, подготовку данных, конфигурирование системы и запуск тестирования в рантайме на ремоутных хостах.

2. Про документацию не понял, что за документация такая на автотесты/фреймворк, которые нельзя хранить прямо в коде?

А где такое написано? Я говорю о том, что если человеку (особенно если он вообще из другой команды) дать скприпт на шеле или руби или перле или еще на чем-то, то если у него возникнут сложности он знает что надо в этот скрипт посмотреть и решить затруднение, не прибегая к помощи того, кто этот инструмент разрабатывал. Но дать, например, EXE файл - то где от него лежат сырцы - надо еще будет поискать.
И да, у нас все это безгуевое. Не надо никуда заходить и ничего нажимать. Все кроны делают.
И конечно, большинство задач решается на разных языках программирования. И буквально сегодня за обедом мы с коллегами говорили, что наиболее _для нас_ удобный язык для тестирования - это bash. Такая специфика.

[stmark]

Понял, что смущает.
Когда-то, когда продукт над которым я работал был плагином к визуал студии, то конечно, я писал на C# тесты, которые использовали API продукта, написанного на C#-же. И писал я их в студии и были эти тесты addon-ом для студии. Это ок. А когда что-то было сделано на базе еклипса, то я писал какие-то тесты на джаве. Не вопрос.
Просто мы о разной автоматизации говорим. Я говорю о целом зоопарке различных скриптов, осуществляющих статические проверки, подготовку данных, конфигурирование системы и запуск тестирования в рантайме на ремоутных хостах.

1. Мы вроде говорим об общем случае, а не о специфичных ситуациях.
2. Ок, то что в Вашей фирме всё очень сложно я понял, только вот дискуссии это не поможет, можно конкретики? В каких именно местах компилируемые языки менее удобные чем интерпретируемые?
3. Расскажу как это делается у нас: программист у себя вносит какие-либо изменения в код, коммитит, далее начинает самоуправство Cruise Control. Изменённый проект начинает билдаться, юнит тесты выполняться, далее наступает очередь UI тестов. Это всё про автобилды, ночные автобилды\анализ кода etc. опускаем, ибо не существенно. Есть и более массивные автотесты, которые запускаются вручную, в общем случае так, как я писал ранее.

А где такое написано? Я говорю о том, что если человеку (особенно если он вообще из другой команды) дать скприпт на шеле или руби или перле или еще на чем-то, то если у него возникнут сложности он знает что надо в этот скрипт посмотреть и решить затруднение, не прибегая к помощи того, кто этот инструмент разрабатывал. Но дать, например, EXE файл - то где от него лежат сырцы - надо еще будет поискать.

А зачем человеку давать exe файл? Человек просто открывает у себя в студии проект с исходникам\ресурсами автотестов, где присутствуют все необходимые пометки\комментарии.

И да, у нас все это безгуевое. Не надо никуда заходить и ничего нажимать. Все кроны делают.
И конечно, большинство задач решается на разных языках программирования. И буквально сегодня за обедом мы с коллегами говорили, что наиболее _для нас_ удобный язык для тестирования - это bash. Такая специфика.

То что конкретно в Вашем случае интерпретируемые языки лучше подходят для тестов верю, но в общем случае it depends.

[theSimplex]

Проголосовал за java. Оч интересуют подобные курсы.

[LeshaL]

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

А где они хуже я уже объяснил. Но могу повторить:
1) В компилируемом языке нужна компиляция или более сложный аналог - билд процедура. В интерпретируемом (для простоты в дальнешем - скриптовом) - не нужно об этом думать.
2) После компиляции у вас есть набор классов, какой-то из них main. Передать эту россыпь другим не предриняв дополнительных усилий не выйдет. Или паковать как-то или что-то типа java-web-start делать, но до этого многие программисты додуматься не могут, что хотеть от тестовых тулов зачастую сделанных на коленке.
3) У скрипта может быть одно место где он живет и откуда запускается всеми. И это место может совпадать с репозиторием где хранятся изменения. Бинарный код в репозиториях хранят редко. Обычно выкладывают в расшареное место или на веб. Потом кто-то отттуда копирует версию Х, а автор уже давно поменял ее на версию Х+10, но старые версии живут в локальных копиях и плодят ненужные ошибки тестирования.
4) Тестовый тул, будучи собранным (скомпилированным) прячет свои исходники. Скрипт сам же и является исходником. Если кто-то хочет что-то исправить "под себя", есму не нужно искать исходники - вот они прямо тут.
5) Тестовый тул, будучи собранным должен как-то нести в себе специальным образом написанную документацию (обычно cmd-line help не достаточен, но если так, то все ок). В скрипте документация тут же и есть, можно просто очитать код если ее недостаточно.
6) Для работы с компилируемыми языками нужно IDE (вы называете это студией), хотя конечно можно и без него. В скриптовых обычно достаточно текстового редактора с подсветкой синтаксиса (лично мне реально так быстрее и удобнее), но можно и с помощью IDE. [ОФТОП]Последнее время развелась порода программистов, спрятавшихся за всякие студии-шмудии. Они даже банально не знают, что нужно их программам чтобы они заработали на компьютере у пользователей! Студия ставит с собой столько дерьма, что хрен разберешь какая там библиотека (dll) нужна. В итоге появляются программы уродцы, которые не могут сказать что им не хватает, но и не работают при этом. И автор программы тоже не знает - у него все работает, а компьютер без дот-нет фреймворка и студии у него вызывает недоумение.[/ОФТОП:]
7) Все это не относится, например, к юнит тестам, или другим регрессионным тестовым наборам. В особенности к тем, которые тестят программу через API или back-doors. Тут выбор языка зависит от самой программы и нет никаких проблем с компилируемым кодом тестов. Они как бы не сторонние инструменты, а дополнение программы. Они написанны для этой программы и не могут быть использованы для другой программы.

[stmark]

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

А где они хуже я уже объяснил. Но могу повторить:
1) В компилируемом языке нужна компиляция или более сложный аналог - билд процедура. В интерпретируемом (для простоты в дальнешем - скриптовом) - не нужно об этом думать.
2) После компиляции у вас есть набор классов, какой-то из них main. Передать эту россыпь другим не предриняв дополнительных усилий не выйдет. Или паковать как-то или что-то типа java-web-start делать, но до этого многие программисты додуматься не могут, что хотеть от тестовых тулов зачастую сделанных на коленке.
3) У скрипта может быть одно место где он живет и откуда запускается всеми. И это место может совпадать с репозиторием где хранятся изменения. Бинарный код в репозиториях хранят редко. Обычно выкладывают в расшареное место или на веб. Потом кто-то отттуда копирует версию Х, а автор уже давно поменял ее на версию Х+10, но старые версии живут в локальных копиях и плодят ненужные ошибки тестирования.
4) Тестовый тул, будучи собранным (скомпилированным) прячет свои исходники. Скрипт сам же и является исходником. Если кто-то хочет что-то исправить "под себя", есму не нужно искать исходники - вот они прямо тут.
5) Тестовый тул, будучи собранным должен как-то нести в себе специальным образом написанную документацию (обычно cmd-line help не достаточен, но если так, то все ок). В скрипте документация тут же и есть, можно просто очитать код если ее недостаточно.
6) Для работы с компилируемыми языками нужно IDE (вы называете это студией), хотя конечно можно и без него. В скриптовых обычно достаточно текстового редактора с подсветкой синтаксиса (лично мне реально так быстрее и удобнее), но можно и с помощью IDE. [ОФТОП]Последнее время развелась порода программистов, спрятавшихся за всякие студии-шмудии. Они даже банально не знают, что нужно их программам чтобы они заработали на компьютере у пользователей! Студия ставит с собой столько дерьма, что хрен разберешь какая там библиотека (dll) нужна. В итоге появляются программы уродцы, которые не могут сказать что им не хватает, но и не работают при этом. И автор программы тоже не знает - у него все работает, а компьютер без дот-нет фреймворка и студии у него вызывает недоумение.[/ОФТОП:]
7) Все это не относится, например, к юнит тестам, или другим регрессионным тестовым наборам. В особенности к тем, которые тестят программу через API или back-doors. Тут выбор языка зависит от самой программы и нет никаких проблем с компилируемым кодом тестов. Они как бы не сторонние инструменты, а дополнение программы. Они написанны для этой программы и не могут быть использованы для другой программы.

1. В чем сложность компиляции? Запустить её? Нажать одну клавишу сложно? При автобилдах вообще ничего не нужно нажимать. Вот честно, не понимаю.
2. Есть SVN в котором всё хранится, одна ссылка и у человека всё есть, все классы, всё ресурсы, все тесты. Один проект, всё структурировано.
3. Не понял, причём тут вообще бинарники? 0o
4. Опять же, работаем с исходниками...
5. *погрустнел* Исходники...
6. Аха, в Вашем случае нужен специальный редактор с подсветкой синтаксиса, не поверите в компилируемых языках *бой барабанов* исходники то же хранятся в виде текстовых файлов и их то же можно хоть через Блокнот редактировать.

>Последнее время развелась порода программистов...
Ну дурачков всегда водилось с избытком
>Студия ставит с собой столько дерьма, что хрен разберешь какая там библиотека (dll) нужна.
Всё можно настроить, всё можно проследить, с помощью студии можно делать совершенно миниатюрные приложения, хоть и заточена она под более массивные проекты.
Многие инструменты встроенные в неё предоставляют множество удобств разработчику, что повышает скорость и качество разработки.

7. Не понял. О чем тогда выше говорилось? Речь ведь шла про автотесты?

[LeshaL]

Ладно, больше вам что-то объяснять смысла не вижу, коль вы не имеете желания понимать. Очень жалко, что люди понимают под автотестами "Press buttons faster and stupider than the fastest and stupidest human can do" (Не нашел точной цитаты Болтона, так что это в моем вольном написании из тетрадочки).

И вот еще цитата из его курса:
"Why think so narrowly about test automation?
Consider thinking of test automation as any use of tools to support testing"

[stmark]

Ладно, больше вам что-то объяснять смысла не вижу, коль вы не имеете желания понимать. Очень жалко, что люди понимают под автотестами "Press buttons faster and stupider than the fastest and stupidest human can do" (Не нашел точной цитаты Болтона, так что это в моем вольном написании из тетрадочки).

И вот еще цитата из его курса:
"Why think so narrowly about test automation?
Consider thinking of test automation as any use of tools to support testing"

Ога, собеседник дурак, я вумный на этом и закончим. Почему нельзя было сразу сформулировать свою мысль? Почему нельзя было сказать "чувак, я говорю обобщённо про все программы\скрипты\etc, а не про автотесты"?
*face palm* В этом смысле у меня половина всех задач заскриптована, начиная со статрта ОС, заканчивая исследовательским тестированием.

[LeshaL]

Ога, собеседник дурак, я вумный на этом и закончим. Почему нельзя было сразу сформулировать свою мысль? Почему нельзя было сказать "чувак, я говорю обобщённо про все программы\скрипты\etc, а не про автотесты"?
*face palm* В этом смысле у меня половина всех задач заскриптована, начиная со статрта ОС, заканчивая исследовательским тестированием.

Зачем вы все-время коверкаете мои слова? Я не называл вас дураком, но если вы сами так хотите...
Я сказал, что вы не хотите понимать, а еще оказывается, даже не читаете, что я пишу (почти два дня назад):

Понял, что смущает.
Когда-то, когда продукт над которым я работал был плагином к визуал студии, то конечно, я писал на C# тесты, которые использовали API продукта, написанного на C#-же. И писал я их в студии и были эти тесты addon-ом для студии. Это ок. А когда что-то было сделано на базе еклипса, то я писал какие-то тесты на джаве. Не вопрос.
Просто мы о разной автоматизации говорим. Я говорю о целом зоопарке различных скриптов, осуществляющих статические проверки, подготовку данных, конфигурирование системы и запуск тестирования в рантайме на ремоутных хостах.

[stmark]

Зачем вы все-время коверкаете мои слова? Я не называл вас дураком, но если вы сами так хотите...
Я сказал, что вы не хотите понимать, а еще оказывается, даже не читаете, что я пишу (почти два дня назад):

Понял, что смущает.
Когда-то, когда продукт над которым я работал был плагином к визуал студии, то конечно, я писал на C# тесты, которые использовали API продукта, написанного на C#-же. И писал я их в студии и были эти тесты addon-ом для студии. Это ок. А когда что-то было сделано на базе еклипса, то я писал какие-то тесты на джаве. Не вопрос.
Просто мы о разной автоматизации говорим. Я говорю о целом зоопарке различных скриптов, осуществляющих статические проверки, подготовку данных, конфигурирование системы и запуск тестирования в рантайме на ремоутных хостах.

1. Зачем же всё понимать буквально? Это было образно, сарказм.
2. Я Вас внимательно читаю, не поверите, даже перечитываю, потому что вижу, что человек Вы умный и есть чему у Вас поучиться. Но вот из той цитаты мне было совершенно непонятно что имелись ввиду не автотесты.

[barancev]

Брэк, брэк, коллеги.
Вы прям устроили языковой холивар, как на каком-нибудь программистском форуме :)
Дело уже даже клонится к холивару vim против MSVS :)
Хорошо ещё, что тут фанатов лиспа нет (или может есть, а?)

Напоминаю, что речь идёт о выборе языковой платформы для написания автотестов с использованием инструмента Selenium, а не для абстрактной автоматизации чего-то сферического в вакууме.

[ch_ip]

Ruby, Ruby, Ruby
там и Cucumber, и rspec, которые последний год очень мощно развивались. И Aquarium, и наверняка что-то еще вкусное есть.
А также динамическая типизация, замыкания, нормальная работа с com-объектами...
Может пару ботов написать на Ruby для поднятия рейтингапопуляризации, так сказать :)

[Panterochka]

Прошло уже более года с того момента, когда мы запустили онлайн-курс "Программирование для тестировщиков".
И ещё тогда, год назад, мне задавали вопрос "почему Java?" и "будут ли другие языки?" Я обещал, что будут -- и вот пришло время.

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

Это будут совершенно другие курсы, нацеленные не на обучение навыкам программирования, а на навыки работы с инструментами. Новые курсы будут более чётко направлены на конкретный инструмент тестирования и конкретный тип тестируемых приложений -- Selenium и веб-приложения. Я буду рассказывать о том, как интегрировать инструменты между собой, как решать типовые проблемы, возникающие при использовании Selenium.

То есть, если вы хотите стать "автоматизатором на все руки" -- тогда вам придётся подождать год, пока будет возобновлён курс "программирование для тестировщиков", а если надо быстро внедрить Selenium -- новые курсы именно для вас!

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

Если лидеров среди языков будет несколько, значит, будет запущено несколько курсов на разных языках.
Голосуйте за свой любимый язык!

Как запустится курс, хотелось бы не пропустить:)

[OVA]

Как ни крути - человечество жаждет яву

[baranceva]

Как запустится курс, хотелось бы не пропустить:)

Всем спасибо за участие в голосовании.

По результатам голосования принято решение провести тренинги на Java и PHP. Тренинги начнутся в конце января- начале февраля. До Нового года будет официальный анонс.

Для тех, кто не хочет пропустить анонс, предлагаю оставить предварительную заявку (письмо в свободной форме на trainings@software-testing.ru) и я в день появления анонса отправляю всем предварительно записавшимся уведомление. Предварительная регистрация ни к чему не обязывает.

Что касается Ruby, то если на этот тренинг есть желающие -- пишите на trainings@software-testing.ru, если до Нового года запишется 10 человек, то поставим и тренинг на Ruby в расписание.

[elibra]

Ну если на то пошло, то тут одним языком не ограничивается. Самый простой и очевидный пример это JUnit vs TestNG.

... на Ruby различия между JUnit vs TestNG не так интересны, как возможность использовать Selenium совместно с Cucumber?

Кстати, тема использования Cucumber в качестве BDD Framework очень даже интерессна, тем более что не так давно появился вариант под Java (cuke4duke или JBehave):

хороший пример с JBehave: http://blog.m.artins...m-page-objects/
http://www.tikalk.co...ng-it-with-java

пример с cuke4duke: http://www.tikalk.co...ng-it-with-java
https://github.com/a...wiki/Javascript
http://old.nabble.co...td22704377.html

Что касается голосования - то я за Java или Ruby. Более даже склонен к первому - понятней, и быстрей в освоении как для бывалого С++ програмиста (или это от того что Алексей так хорошо преподает :).
Пробовал Ruby (в связке с Cucumber), как то туговато оно пошло, хотя и используется на одном нашем крупном проекте, но и там видать не особо в восторге в плане скорости освоения.

Мне кажется если в компании Java-веб програмисты то всем (и тестировщикам и пограммистам) будет легче работать с тестами написанными на Java. А для того чтобы и бизнес-уровень более естественно интегрировался с разработкой и тестированием, Cucumber фреймворк, как BDD надстройка над тестами - самое то.

Хотелось бы только разобраться как правильней "подружить" Cucumber с теми подходами которым Алексей обучает на тренинге ПДТ.

[baranceva]

Определены даты новых курсов.

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

• Разработка автоматизированных тестов на Java с использованием Selenium
  Начало: 24.02.2011, 17:00 (6 занятий)
• Разработка автоматизированных тестов на PHP с использованием Selenium
  Начало: 31.03.2011, 14:30 (6 занятий)

[frei_by]

Почитал программу для курса на PHP.

По первому модулю -
"как с нуля развернуть всё необходимое для разработки и выполнения тестов,"
- я так понимаю имеется ввиду SeleniumRC + PHP + Pear(чтобы phpunit притянуть) + PHPUnit + расширения классов для PHPUnit для Selenium RC?
++ Oracle VB в качестве виртуалки?

"как отлаживать тесты, проходя их в пошаговом режиме" - средствами PHP есть множество способов контролировать выполнение скрипта. Я правильно понимаю что это будет сделано средствами PHP + просмотр лога Selenium ?

"как сделать гибкий механизм настройки на тестовый стенд при помощи конфигурационных файлов," - это насколько я понимаю по большей части к средствам PHPUnit вопрос, или про профили броузеров.

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

"как запускать тесты в разных браузерах и на удалённой машине." - настройки сети + удалённая командная строка..

Хотелось бы подробнее почитать о программе. Если можно с перечислением названий фреймворков и инструментов.

[barancev]

Да, это ещё не программа, это только анонс.
Программа будет чуть позже, с подробностями, с перечислением конкретных фреймворков, инструментов, расширений.
Я планирую полностью завершить формирование программы к окончанию новогодних каникул, то есть к 11 января.

Кстати, участники форума находятся в привилегированном положении -- вы можете высказать свои пожелания относительно того, что включить в программу, и я постараюсь это сделать, если позволит время всё вместить :)