Я почерпнул очередную порцию вдохновения из статьи про выбор языка программирования (опять критичной и бескомпромиссной) и решил написать свои мысли по этому поводу. С большей частью предложенных в статье критериев я не согласен, поэтому мой список будет “альтернативным”. Итак, на что же обращать внимание при выборе языка программирования для тестов?

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

1. Наличие надежной и хорошо поддерживаемой версии инструмента для тестирования.

Этот пункт недаром стоит на первом месте. Инструменты и фреймворки действительно появляются как грибы после дождя каждый день. Но при этом некоторые из них регулярно выпускают обновления, поддерживаются большим сообществом и постоянно развиваются. А другие просто опубликованы автором как результат эксперимента или локальной разработки. В качестве примера приведу PHP клиента для WebDriver – существует несколько реализаций, ни одна из которых “не признана официально”. Все они гораздо сложнее своих аналогов в других языках программирования и развиваются независимо. Поэтому PHP не стоит использовать для тестирования с WebDriver напрямую (есть библиотеки, которые содержат свои прослойки над WebDriver API).

2. Знание языка членами команды.

В этом пункте речь идет не только о тестировщиках, но и обязательно о разработчиках. У них должна быть возможность поправить тесты в случае изменения деталей реализации приложения (расположение элементов, тип элементов, переходы между страницами и т.д.). Иначе успешной автоматизации вам не видать – скоро все время тестировщиков будет уходить на поддержку тестов в рабочем состоянии. Причем, это должно быть достаточно легкая операция с точки зрения знаний языка. И вовсе необязательно это должен быть тот язык, на котором разрабатывается само приложение. Если все члены команды разбираются в синтаксисе Python, а приложение пишется на Java, то можно выбрать любой из этих языков.

3. Наличие хорошего IDE.

Этот пункт особенно важен для тех команд, где работать с автотестами будут даже неопытные с точки зрения программирования тестировщики. Хорошее IDE помогает многие вещи генерировать вместо того, чтобы набирать руками. Также гораздо ниже вероятность допустить ошибку, потому что IDE подсвечивает потенциальные проблемы и контролирует код по мере его появления. В этом пункте также стоит подумать над вопросом динамических и статических языков. У динамических обычно код тестов гораздо более читабельный и простой. У статических более громоздкий, но зато меньше подвержен “неожиданным” ошибкам начинающих тестировщиков. Хорошим примером являются Groovy и Java. Оба языка позволяют писать код с привычным Java синтаксисом, но многие вещи можно сделать значительно проще на уровне языка Groovy (работа с коллекциями, файлами, базой данных и т.д.).

4. Наличие готовых решений для вашего контекста тестирования.

Иногда в каком-то языке выбор готовых решений на порядок больше, чем в других языках. При прочих равных условиях стоит выбрать тот, в котором есть готовое решение, ближе всего к вашему контексту тестирования. Это избавит вас от необходимости писать многие вещи самостоятельно. Из моего опыта, больше всего решений в области автоматизации тестирования сделано для Java и Ruby.

5. Опыт использования в компании.

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

6. Простота изучения языка.

Этот пункт я поставил последним, потому что для автоматизации тестирования достаточно очень узкого подмножества возможностей языка. Изучаются они обычно недолго, особенно под присмотром разработчиков. Процесс обязательного ревью кода тестов также помогает в короткие сроки распространить знания об основах языка. Поэтому на первое место выходят возможности писать читабельные и хорошо структурированные тесты. В этом снова может сильно помочь готовое решение с установленными правилами. Например, в Thucydides есть четкое разделение между частями тестов, благодаря которому тяжелее сделать плохо структурированные тесты (при большом желании конечно все возможно).

А на что обращаете внимание вы при выборе языка? Были ли ситуации, в которых выбор был сделан неверно и привел к нежелательным результатам?

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!