Вечный вопрос выбора языка программирования, заставляет хорошо подумать не одного специалиста по автоматизации. Я не буду разсказывать какие 100%-е правила должны использоваться при выборе языка программирования, потому что их НЕТ. Тем более, я не программировал на Ruby и мне тяжело судить о нем.
Могу лишь дать рекомендации которым я придерживаюсь:
Язык программирования может релизовать все нужно разработать в соответствии с какой-то целью.
Язык программирования максимально соответствует окружению разработки, чтобы в нужном случае можно было использовать исходный код проекта.
Язык программирования имеет хорошую инструментальную поддержку. Т.е. различные дополнительные библиотеки расширения, юнит фреймворки, среда разработки, и т.д.
Распространение и популярность. А именно, комьюнити и форумы на которых можно найти ответ.
По поводу самого языка, я слышал, что Ruby гибче и более читабильнее, соответственно значительно меньше кода. Зато Java более производительнее. Вот слайдик:
Я указал сравнение двух языков, т.е в чем отличие.
Производительность инструмента автоматизации, производительность среды в которой запускаются тесты, и производительность тестируемого приложения - являются очень значительными факторами, которые влияют на скорость выполнения автоматизации.
Но, это никак не относиться к выбору языка программирования для автотестов, т.е. производительность языка
никак не является фактором выбора :)
Когда есть выбор, какой ЯП использовать, то лучше выбирать тот, который для данной задачи предоставит больше возможностей. Если выбор делается из ЯП общего назначения, то значительная часть их возможностей примерно одинакова. Хотя, все равно есть особенности. Например, если ваши тесты надо будет запускать на Линуксе, то C# - не самый лучший выбор, даже если вы на нем всe можете сделать максимально быстро.
Я обычно предпочитаю выбирать ЯП для тестов так, чтобы это был тот же язык, на котором сама система и разрабатывается. Такой выбор обеспечивает ряд преимуществ:
1) Интегрируемость - вы можете интегрировать ваше решение с юнит-тестами. При этом вы даже можете использовать ряд функций для низкоуровневых тестов, чтобы увеличить производительность тестов (например вы можете сделать небольшой запрос, чтобы создать какую-то запись, а не делать это все через ГУИ)
2) Унифицировнность - не нужно разводить "зоопарк" технологий. Потом ведь это все надо поддерживать.
3) Возможность использовать ту же инфраструктуру и вспомогательные средства, что используются при разработке приложений - не секрет, что инструментария для разработки заметно больше и он намного разнообразнее, чем для автоматизации.
К несчастью, это не всегда возможно или осуществимо. Да и на некоторых ЯП писать ГУИ-тесты несколько стремно. Для примера, представьте, как выглядят ГУИ-тесты на Ассемблере (это, наверное, уже к Чаку Норрису) или на С++ (я уже такое видел, теперь я не боюсь ничего).
Если язык программирования такой же как и при разработке, тогда разработчики тоже могут помогать писать автоматизацию, когда будет свободное время. Но это уже плюс для менеджера, из разряда: "хорошо бы иметь так возможноть, если вдруг..." :)
А GUI тесты на С++ кажется чем-то таким, я незнаю, нереальным. Страшно представить. Помниться мне лабораторки на паскале и С! Ех....
А GUI тесты на С++ кажется чем-то таким, я незнаю, нереальным. Страшно
представить. Помниться мне лабораторки на паскале и С! Ех....
Кстати, сталкивался с таким, но это действительно из разряда "хардкора". Таким образом тестировалась апликуха, которая встраивалась в звуковое оборудование. Там вообще автоматизация встроенная была в само приложение. Зато потом подобные тесты активно использовались для диагностики системы со стороны пользователей. А поскольку само приложение было на С++, то и его тестирующую часть пришлось делать тоже на С++.