У TestComplete, как у любого программного продукта, есть недостатки, которые могут оказаться неприятным сюрпризом, когда вы освоились с продуктом и пытаетесь делать, казалось бы, обычные вещи. В этой статье я рассмотрю такие недостатки. Если вы хотите добавить сюда что-то — пришлите мне письмо на karkadil@gmail.com.
Автодополнение кода и просмотр методов
Хотя TestComplete поддерживает возможности ООП, предоставляемые языками программирования, автодополнение (также известное как IntelliSense) в нём работает отвратительно. В выпадающем списке появляются только обычные функции, методы или классы (например, в JScript) не видны в принципе (ни в выпадающем списке редактора кода, ни в списке методов на панели инструментов). Ну ладно бы в JScript, где нет понятия класса как такового, но оно не работает даже в языках типа Python, что уж совершенно отвратительно.
Как видно из скриншота, TestComplete может лишь более-менее отображать статические методы JScript. В выпадающем списке панели инструментов нет методов (myMethod) и нет класса MyAnotherClass (который просто объявлен немного иначе, чем MyClass). Когда же мы ставим точку после имени объекта, TestComplete вообще отображает ошибку, хотя должен отображать список доступных свойств и методов класса.
Естественно, про такие вещи, как переход по Ctrl+click на метод и список параметров (Ctrl+Shift+пробел) можно также забыть. Для любого опытного автоматизатора это серьёзный недостаток.
Форматы служебных файлов (pjs, mds, tcNM и другие)
Формат служебных файлов TestComplete – XML, однако в них повсюду используются GUID-ы, которые не позволяют нормально прослеживать связи между элементами. Например, вот скриншот TestItem-ов проекта и кусок соответствующего MDS-файла:
Да, кое-что понять можно (например, включен ли соответствующий TestItem и сколько раз его нужно запускать), однако в какой группе он находится? С какой функцией из какого модуля он связан?
Нам нечасто приходится просматривать содержимое этих файлов в текстовом виде, однако нам приходится мерджить изменения и решать конфликты, а использование подобного формата делает подобные задачи просто нереально трудными. О нормальной коллективной работе над проектом можно забыть, приходится изобретать воркэраунды (например, когда NameMapping редактирует сначала один человек, затем другой, или всегда кто-то один).
Сюда же можно отнести совершенно непонятный способ TestComplete-a работать с INI-файлами. TestComplete требует, чтобы у файлов этого типа была обязательная секция [root], что делает невозможным работу с 99.9% файлов такого типа.
Невозможность просмотра/редактирования DDT-файлов
Многие коммерческие инструменты автоматизации (например, QTP, Squish) предоставляют встроенные возможности для редактирования DDT-файлов (Excel, CSV и т.п.). К сожалению, в TestComplete такой возможности нет. Конечно, есть много бесплатных приложений, которые позволяют работать с такими файлами (LibreOffice, пожалуй, самый мощный из них), однако это не так удобно, как если бы такой редактор был встроен в TestComplete.
Ещё одно неудобство, связанное с отсутствием подобной возможности в TestComplete — невозможность охватить одним взглядом все внешние данные, используемые в проекте. Добавление файлов DDT в коллекцию Files не очень удобно, так невозможно из TestComplete открыть файл во внешнем редакторе (например, двойным кликом).
Невозможность остановить выполнение скрипта в некоторых случаях
В некоторых случаях невозможно остановить выполнение скрипта TestComplete, пока не закончится текущая операция. Например, команда aqUtils.Delay не позволяет поставить скрипт на паузу, пока не пройдёт всё время, переданное в Delay в качестве параметра, а при выполнении запроса к базе данных невозможно остановить выполнение теста.
Некоторые из этих проблем можно обойти (например, решение проблемы с паузой при Delay), но ту же проблему с выполнением SQL-запроса решить невозможно. Если по какой-то причине SQL запрос завис на стороне сервера, нам придётся завершать процесс TestComplete.exe через Task Manager.
Запуск TestItem-ов из командной строки
TestItem-ы используются в TestComplete для организации и запуска тестов, этот функционал присутствовал в TestComplete много лет, однако возможность запустить конкретный TestItem из командной строки появилась только в 12 версии инструмента. В течение многих лет (влоть до 11 версии включительно) отдельные тесты приходилось запускать по имени функции, а для запуска группы тестов приходилось писать отдельную функцию, из которой вызывались нужные тесты. Другой способ, который предлагет SmartBear – использование довольно сложного скрипта, который подключался к TestComplete через COM.
Ситуацию также усложняла терминология: в справочной системе использовалось понятие Project Item, что было довольно похоже на Test Item, а потому пользователи безуспешно пытались снова и снова запускать отдельные TestItem-ы из командной строки.
Правда, даже в 12 версии эта возможность реализована не до конца, так как нет возможности запускать TestItem-ы, которые требуют передачи параметров. Чтобы реализовать подобную функциональность, придётся парсить командную строку, как это показано в этой статье.
Некоторые особенности Debug-режима
У режима Debug в TestComplete тоже есть свои неприятные особенности.
1. Панель Call Stack и блок try…catch
В случае перехваченного исключения в логе или debug-режиме невозможно понять, где именно произошло это исключение. Вот пример кода, который вызывает исключение, и Call Stack лога:
Как видно, из лога мы можем перейти либо на строку 12 в блок catch, либо на строку 2, откуда была вызвана функция fun2. Однако мы не знаем, на какой именно строке блока try возникло исключение.
2. Панель Watch List
Ещё один недостаток — автоматический пересчёт значений выражений панели Watch List. Допустим в предыдущей сессии отладки мы добавии на панель Watch List функцию, которая выполняется достаточно долго (например, ждёт появления какого-то объекта в течение минуты). В следующей сессии отадки TestComplete окажется недоступен на эту минуту: пока не пересчитает все значения окна Watch List, даже если они нам в данный момент не нужны и просто остались с прошлого раза.
3. Доступ к Call Stack из кода
Из кода невозможно получить информацию, которую мы видим на панели Call Stack (это было бы удобно в случае, когда генерируется кастомный отчёт).
Поиск в TestComplete также имеет свои недостатки.
Во-первых, если у нас большой проект и файлы находятся внутри логических папок в Project Explorer, мы не можем сделать сквозной поиск только в определённой папке, только по всему проекту. В принципе это неудобство можно обойти, для чего нужно сначала закрыть все открытые документы панели Workspace, затем открыть только документы из логической папки и произвести поиск с опцией Look in = Open Documents, как показано на скриншоте:
Во-вторых, окно Find в TestComplete выборочно запоминает настройки поиска. Содержимое группы Find Options сохраняется (т.е. опции будут такие же, какие были при прошлом поиске), однако опция Look in не сохраняет своё состояние, так что если вам приходится чаще искать во всём проекте, чем в текущем документе, вам каждый раз придётся выбирать эту опцию из списка.
Версия TestComplete
Последний недостаток, о котором стоит упомянуть, — это новые версии TestComplete. Читая форумы по TestComplete несколько лет я обратил внимание, что количество багов, которые пользователи находят в TestComplete, сильно возрастает каждый раз, когда выходит очередная major версия (x.0). Стоит упомянуть, что эти баги SmartBear обычно чинит довольно быстро, однако если нет острой необходимости переходить на новую версию x.0, то лучше подождать выхода версии x.1, в которой большинство недочётов будет устранено.