Загрузка файлов клиентом и Selenium

В целях автоматизации тестирования  некоторых сценариев точечно применяю Selenium-тесты на perl-е + Selenium RC.
До сих пор не приходилось сталкиваться с автоматизацией кейсов, связанных  с аплоадом файлов. И вот такая необходимость возникла.
Итак , запускаю Firefox + Selenium IDE , записываю действия по аплоаду и экспортирую в perl-виде.
Смотрю, какими же командами IDE мне сэмулировал нужную последовательность. Удивленно вижу, что для указания нужного файла используется всего навсего type с локатором файлового INPUT-поля и полным путем файла.
Отсекаю лишнее ,добавляю нужное , встраиваю в perl-фреймворк и вижу , что тест не проходит.
Копаю perl-библиотеку для работы с Selenium (WWW::Selenium) , радостно нахожу команду attach_file , пытаюсь ее применить и не получаю результата.
Гуглю, вижу всяческие рецепты,  как можно извратиться с помощью спец js-скриптов, дополнительных exe-утилит (для Windows).. Ни то ни то не подходит. Как раз в тот момент, когда хотелось "забить" на аплоад, в "буржнете" попался очень простой совет - принудительно установить фокус на поле с именем файла после его заполнения. НЕ веря в успех, попробовал и получилось...Работает (в *chrome - режиме) , аплоадит, тестируется =)

p.s.
По поводу Selenium 2.0 - слышал, что там проблема пользовательского аплоада стоит гораздо менее остро. Лишний повод познакомится и попробовать.

UPD 22/08/2011:
Перечитал пост и понял, что из него до конца неясно, какая же последовательность команд решает проблему? Ответ: focus +  type . attachfile можно вообще не использовать. По крайней мере, в моей ситуации со стандартными контролами пользы от этой команды  никакой.

Лень и кроссплатформенные баги

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

Вот пример: Разработчику поступила задача слобать некий cgi-скрипт. Веб-продукт, частью которого будет этот cgi-скрипт , заявлен как работающий под любой *nix - системой: Linux, FreeBSD, Solaris ..etc
По ходу дела девелопер сталкивается  с необходимостью работы с датами. В любом уважающем себя языке программирования, особенно в скриптовом, есть библиотеки для кроссплатформенной работы с датами. Но с ними надо разбираться, читать маны..разработчику ( кодящему , к примеру, в linux) неохота, ведь он знает быстрый способ - запустить из скрипта консольный date с нужными ему флагами и распарсить вывод этой команды. Сказано - сделано. date убран в обратные кавычки (если это,  к примеру perl), вывод распарсен, дата в нужном формате получена и в итоге скрипт написан и вроде как работает...У тестирования, к примеру, цейтнот и есть время на проверку в самой распространенной конфигурации, которой, к примеру является работа на  linux.... Или же тоже лень проверять во всех конфигурация... В общем ,  протестировали в linux - все ок. Релиз. В итоге находится пользователь, который ставит продукт на Solaris и получает 500-тки. Ругается и топает ногами "За что я заплатил деньги".. При разборе полета выясняется , что у GNU-той команды date  в SunOs совсем другие параметры, из-за чего скрипт ленивого разработчика аварийно завершается.

В общем лень лени рознь. Разработчикам советы давать не охота, а вот нам - тестировщикам , посоветовал бы не лениться ;)

Тестовый smtp-сервер в одну строчку

Недавно я делился советом о том, как быстро поднять тестовый http сервер в произвольной директории. Вот еще еще одна плюшка от python-a, которая может сэкономить немало времени в определенных ситуациях..
Например, вы разработчик и кодите нечто, что должно отправлять почтовые сообщения по smtp. Или же вы тестировщик, который должен проверить отправку неким приложением письма.
Вот практический совет, как поднять тестовый smtp-сервер, который будет принимать сообщения по указанному порту и дампить их на stdout:


python -m smtpd -n -c DebuggingServer localhost:1025


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

grep по сетевым пакетам

Тем, кто знает , зачем может понадобиться сниффать сетевые пакеты, анализировать их содержимое хочу посоветовать GNU-утилиту ngrep, которая позволяет с легкостью проводить в реальном (!) времени grep по содержимому сетевых пакетов.
Утилита есть в репозиториях практически всех linux-дистрибутивов.
Подробно о ее возможностях можно узнать в ее man-е , а также на странице проекта.

Пример: "Поиск в HTTP-пакетах дефолтного интерфейса по строке 'login' "

sudo ngrep 'login' -W byline  port 80

Результат:


 T 10.33.4.105:46837 -> 10.33.4.106:80 [AP]
GET /cgi-bin/clients/STUB?login=type%20login%20here&psw=ecaae631e3e96de095a45d015c3b4e99&phones=74953222233&mes=messagetext.&charset=utf-8 HTTP/1.1.
TE: deflate,gzip;q=0.3.
Connection: TE, close.
Host: some.host.name.
User-Agent: libwww-perl/5.837.
.

##
T 10.33.4.106:80 -> 10.33.4.105:46837 [AP]
HTTP/1.1 200 OK.
Date: Wed, 03 Aug 2011 11:39:43 GMT.
Server: Apache/2.2.3 (CentOS).
Connection: close.
Transfer-Encoding: chunked.
Content-Type: text/html; charset=ISO-8859-1.
.
54.
$VAR1 = 'login';
$VAR2 = 'psw';
$VAR3 = 'phones';
$VAR4 = 'mes';
$VAR5 = 'charset';