Но если взять конференцию, которая может быть не столько интересна в данный момент (поскольку недавно уже проходила), да встроить её в контекст другой известной конференции, то получится может очень даже удачно. Ведь при построении коммерции на образовании главное это не знания, а иллюзия удовлетворённости у посетителя. Я надеюсь, что в случае с SQA Days всё-таки будет не так пессимистично, как я себе представил, потому что планирую её посетить. Но как бы там ни было, вторая конференция за этот год пройдёт в рамках SECR 2009.

Конкретно о самих конференциях пока ничего сказать невозможно, потому что программы конференций не готовы. Известно только, что на SECR будут выступать Ларс Бак (Google Chrome), Гради Буч (похоже, что физически на конференции его не будет) и Юрий Гуревич (Microsoft).

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

Основные даты конференции:

30 Июня: завершение приема докладов
31 Июля: завершение предварительной регистрации
1 Сентября: уведомление авторов принятых докладов
15 Сентября: завершение регистрации участников
1 Октября: завершение приема окончательных версий докладов
28-29 Октября: конференция

Я не противнки итерационных методов, но и не считаю возможным их применение в широком спектре случаев. Впрочем я и не настолько хорошо знаю Agile, как Асхат Урузбаев. Зато точно знаю, что Agile будет жить в компании только в том случае, если этого хочет её хозяин. А захочет он этого только если всё будет спокойно в бизнесе и станет интересно за что наёмные рабочие получают зарпалату, либо если бизнес планируется сделать публичным (читать приятным для инвесторов и заказчиков) или продать. В других случаях итерационный процесс всегда привязан к Business Needs и заканчивается и начинается именно с них.

Для начала стоит посмотреть назад в недалёкое прошлое, когда Opera выпустила движок Futhark, входящий в соств Presto (2003 год). На тот момент он был самым быстрым на рынке, хотя никто особо не придавал значения этому языку. Сравнения по производительности стоит посмотреть в статье JavaScript Performance Rundown Джона Ресига (John Resig). Джон получил интересные результаты из которых видно, что сейчас движок браузера Opera не блещет. В отличие от него Carakan построен на других принципах и обещает быть не только быстрым, но и экономичным. Для этого уже сделано следующее:

1. Принцип обработка в стеке заменен на обработку в регистрах (ничего общего с регистрами процессора). Фактически, сейчас инструкции псевдокода JS забирают значения из стека и помещают их обратно после обработки, доступ идет только к верхнему элементу, что сказывается на производительности. В Carakan динамечный стек со значениями заменен на фиксированный блок значений и инструкции псевдокода могут обращаться к любой ячейке.

2. Генерация нативного кода. Это, как я понял, попытка решить проблемы с арифметикой за счет расширения стандартных возможностей ECMAScript. Пока еще ведуться работы для ARM, для x86 (32 и 64 бита) уже всё готово.

3. Автоматическая классификация объектов. Смысл в том, что на уровне движка создаётся виртуальное наследование при котором каждому базовому объекту из ECMAScript приписывается класс, описывающий его. Дальше во время жизни и модификации объектов движок классифицирует их по первичным прототипам (тем самым объектам из ECMAScript). В результате это позволяет использовать меньше памяти (как то очень уж это оптимистично) и при поиске объектов кешировать результаты. Если это будет реализовано добротно, то производительность Carakan в Cloud Apps будет действительно потрясающая.

Дженс Линдсром (Jens Lindström) пишет, что даже без нативной генерации кода скорость Carakan в два с половиной раза больше, чем последняя версия Presto по тесту SunSpider. А вот при включении нативной генерации скорость может быть выше в 5 или 50 раз (или 500, почему бы нет?). Но обещать что либо еще слишком рано.

• Internet Explorer (5.5 – 7.0)
• Firefox (1, 1.5, 2)
• Safari (1.3, 2.0, 3)
• Opera (9.2, 9.5)

Так же плагин поддерживает поиск по элементам и атрибутам HTML и по свойствам CSS.

Домашняя страниц: Firescope

Сами описания ошибок можно посмотреть на сайте сообщеста Common Weakness Enumeration.

Некоторые моменты в переводе были для меня сложны и некоторые термины и определения переведены на русский дословно. При первом появлении для каждого специального термина в скобках приводится его английский источник. Например, для User Stories я предпочитаю использовать перевод «пользовательские истории», поскольку в большинстве случаев это подходит лучше, чем «пользовательские рассказы» или «идеи пользователя».

Так же в некоторых случаях, когда трудно подобрать синоним, либо одно слово объясняется предложением, используется принятый за стандартный жаргон, например: логин – как сущность, так и как действие.

Приёмочное тестирование (Acceptance testing) web-приложений с PHP

Введение

В этой статье я расскажу о приёмочном тестировании (также известного как – функциональное тестирование), кое-что большинство PHP программистов смогут использовать в своей повседненвной практике. Я уверен, что многие из нас хорошо знакомы с юнит тестированием (unit testing), и даже интеграционным тестированием (Integration Testing), где же эта «лишняя спица в колесе» появляется при тестировании веб-приложений при нашей растущей одержимости Web 2.0 и AJAX, и как она отличается от первых двух методов? Ниже я объясню это. Также я покажу, как сделать приёмочное испытание с использованием убийственного сочетания PHPUnit и Selenium.

Зачем нужны приёмочные испытания?

Приёмочные испытания позволяют определить работает ли приложение так, как ожидает клиент (тот, кто заказал приложение). Теперь о том, что это означает…

Иногда трудно понять, как использовать приёмочные тесты при тестировании. Некоторые люди видят их подозрительно похожими (если не идентичными) на интеграционное тестирование. Интеграционное тестирование другой уровень процесса тестирования, отличный от юнит тестирования, которое проверяет, что компоненты приложения работают так, как ожидалось. Как и в случае с юнит тестами, это тестирование, как правило, занимается проверкой мест изолированных от остального кода с помощью MOCK объектов, заглушек и специальных тестовых классов.

Главное отличие приёмочных тестов в том, что они довольно просты. Интеграционные тесты работают по аналогии с юнит тестами, но с целыми группами связанных классов. Акцент делается на концепции «группы». Мы не тестируем каждый класс в отдельности, как с юнит тестами, а тестируем группы классов, которые вместе создают желаемый результат. Интеграционные тесты, поэтому написаны для и пишутся самими программистами. С другой стороны, приёмочные тесты работают для всего приложения (без изоляции классов и компонентов), как правило, по отношению к интерфейсу пользователя (прим. в данном случае имеется ввиду не только графический интерфейс, но и любой другой реализованный в виде запросов и видимых ответов), не важно для браузеров или веб-служб. Они пишутся для обеспечения соответствия приложения целям определенных клиентом. По сути, клиент даже может отвечать за написание тестов!

Теперь мы знаем, что приёмочное тестирование является самостоятельной практикой, но зачем нам её использовать?

1. Она отражает ожидания клиента (а не для разработчиков!);
2. Она оценивает, когда функциональность значимая для клиента закончена (знание о том, когда нужно остановиться);
3. Она гарантирует быстрое определение будущего поведения, которое отличается от ожидаемого (регрессионное тестирование);
4. Как любой хороший набор тестов она поддерживает рефакторинг в том же порядке, как юнит и интеграционные тесты.

О пользовательских историях (User Stories) и приёмочных тестах

Для тех, кто практикует экстремальное программирование, приёмочные тесты обычно пишутся для того, чтобы установить, что соответствие “пользовательским историям” является полным и не отклоняется от них в течение разработки.

Пользовательские истории – это краткое описание заказчиком некоторых частей значимой функциональности приложения, то есть ожидаемое поведение, которое должны проверять при приёмочных тестах. В плане XP (eXtreme Programming) это заменяет традиционную зависимость от спецификации, которая описывает каждый шаг в развитии, за счет жесткости в исполнении, с более гибким подходом, где наборы пользовательских историй отслеживают текущие требования. Пользовательские истории ведутся с пониманием положения, что план любого релиза, основанного на них, может подвергаться частым изменениям.

Давайте кратко посмотрим на написание пользовательских историй.

Клиент может авторизоваться на сайте.

Как PHP разработчики некоторые из нас могут посчитать это тупым и очевидным требованием. Старайтесь не думать так. Для клиента это важная функция. Если предположить, что дальнейшие обсуждения с клиентом не вызовут никаких изменений в этой пользовательской истории, то мы можем написать приёмочные тесты еще до начала разработки. Этот процесс звучит похоже на юнит тестирование – сначала тесты, потом код (прим. На самом деле не совсем так и тут сказывается то, что автор больше работал в условиях XP или TDD, в условиях многомодульных проектов следование такому правилу себе дороже). Вы можете оценить успешность реализации, независимо от того, все ли предварительно написанные тесты успешно пройдены (в нашем случае для веб-интерфейса). Дальше, после обсуждения идей с программистами клиент написал следующие тесты.

1. Страница авторизации отображает форму для входа;
2. Отправка правильного сочетания идентификатора пользователя и пароля приводит к успешной авторизации;
3. Отправка недействительной пары логин – пароль, показать регистрационную форму с указанием ошибок;
4. Форма для логина всегда сопровождается гиперссылкой “Забыли логин или пароль?”.

Неплохо выглядит, не так ли? Эта четверка тестов уже вторая пользовательская история, дополнительные ценные знания о важной функциональности для клиента.

Клиент может восстановить забытый логин и пароль

Если каждый из четырех тестов проходит, мы можем считать, что обе пользовательских истории реализованы. Кроме того, при приёмочных тестах это явный сигнал, что пора прекратить разработку для этой функциональности. Если только клиент не придёт с новыми идеями (или уточнением существующих) нет причин расходовать ресурсы на неё. Это сделано! Вперёд!

Итерации

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

Подготовка к приёмочному тестированию

Требования:

• PHPUnit 3.0 http://www.phpunit.de
• Testing_Selenium http://pear.php.net/
• Java 5 (1.5.0) требуется для Selenium RC http://java.sun.com
• Selenium Remote Control (RC) http://openqa.org/

Многие PHP программисты стремятся использовать PHP библиотеки для написания приёмочных тестов, и это подход я использую здесь. В этой статье мы будем использовать PHPUnit, который с версии 3.0 содержит класс PHPUnit_Extensions_SeleniumTestCase, который может быть использован для определения приёмочных тестов и используется с Selenium Core при тестировании. Важно отметить, что эти тесты не являются юнит тестами. Да, PHPUnit это библиотеки для юнит тестирования, но они столь же эффективны для интеграционных и приёмочных тестов.

Руководство по использованию PHPUnit с Selenium можно почитать тут: http://www.phpunit.de/pocket_guide/3.1/en/selenium.html. Расширение PHPUnit для Selenium также потребует, установленного пакета PEAR Testing_Selenium. PHPUnit и Testing_Selenium могут быть взяты из PEAR (PHPUnit 3 доступен только через phpunit.de, руководство по установке тут http://www.phpunit.de/pocket_guide/3.1/).

Selenium это веб-приложение для приёмочного тестирования ( прим. не совсем верно. Selenium это всё-таки функциональное тестирование, но может быть использован и для приёмочного) веб-приложений, созданное ThoughtWorks. В него входит несколько пакетов приложений, включая Selenium Core, Selenium RC и Selenium IDE. Его цель состоит в том, чтобы запустить тесты в реальном браузере (со всеми тараканами и примочками!), используя Selenium Core для воспроизведения действия пользователя, их проверки и создания отчетов с результатами тестирования. Selenium Core написан на Javascript и содержит в себе “BrowserBot”. Selenium Remote Control – это дополнительный сервер, который потребуется для запуска тестов приведенных в этой статье. Он позволяет использовать любой язык программирования для взаимодействия с Selenium Core в браузере через посылку простых HTTP GET запросов на сервер RC. Все это звучит сложно, но работать с ним просто.

Обратите внимание, что прошло много времени с момента последнего релиза Selenium RC 0.9.0 (привет 2006 году),в этой статье я рекомендую использовать снапшот Selenium 0.9.2. Это необходимо, поскольку версия 0.9.0 не очень хорошо работает с последними версиями Firefox 2 и Internet Explorer 7 (прим. последние релизы Selenium RC и Core были сделаны в январе 2009 (буквально вчера), поэтому плясать с бубном не нужно, но нет гарантий, что тесты из этой статьи заработают). Из архива Selenium RC потребуется только один JAR файл с названием “selenium-server-standalone.jar”.

Базовая форма приёмочных тестов с применением PHPUnit и Selenium RC очень проста.

/** PHPUnit_Extensions_SeleniumTestCase */
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class GoogleIndexTest extends PHPUnit_Extensions_SeleniumTestCase
{
protected function setUp()
{
/**
* ‘*firefox’ => Firefox 1 or 2
* ‘*iexplore’ => Internet Explorer (all)
* ‘*custom /path/to/browser/binary => Любые другие браузеры (включая Firefox в Linux)
* ‘*iehta’ => экспериментальный встроенный IE
* ‘*chrome’ => Экспериментальный профайл для Firefox (не браузер Chrome)
*/
$this->setBrowser(‘*firefox’);
$this->setBrowserUrl(‘http://www.google.ie/’); // сайт, который будем тестировать
}

public function testTitle()
{
$this->open(‘http://www.google.ie/’); // открыть дефолтную страницу
$this->assertTitleEquals(‘Google’); // проверить существует ли ожидаемый заголовок (title).
}
}

Метод SetUp ()используется для определения наших тестов, начнём тут с указания какой браузер использовать. Firefox – один из возможных вариантов. Если Selenium RC не содержит ссылка на ваш браузер вы можете использовать префикс “*custom” и путь до браузера. Функция setBrowserUrl () устанавливает основной URL для тестов. Обычно это главная (начальная) страница вашего приложения (например, index.php). Страница доступна для тестов, только когда она открыта (если это не очевидно). Поэтому тесты лучше начинать с открытия страницы с помощью функции open().

Selenium Core (Javascript BrowserBot) работает в окне браузера, что происходит достаточно просто понять после небольшой практики. Существует пять концепций, которые необходимо понять с самого начала:

1. Действия (Actions, Selenium Actions)
2. Accessors
3. Assertions
4. Локатор элементов (Element Locators)
5. Шаблоны (Patterns)

Действия просто все ожидаемые действия, которые могут манипулировать состоянием веб интерфейса. Действия включают в себя нажатие на ссылку, нажатие клавиш, позиционирование мыши (например, onmouseover) и так далее. Все, что пользователь может сделать, Selenium Actions могут сделать тоже. Многим действия может быть указано ожидать определенного состояния. Самым простым является суффикс “AndWait”, который можно прикрепить к действиям, например, clickAndWait(). Это указывает Selenium, что после нужно отправить запрос на веб сервер и дождаться ответа перед тем как продолжить. Из-за изворотливого характера Selenium RC я рекомендую вам избегать использования “WaitFor” (ужасно работает в версии 0.9 и снапшоте 0.9.2 (прим. в 1.0 вроде ничего так)) и использовать отдельный вызов “waitForPageToLoad()”, – мы рассмотрим это действие позже.

Accessors – отслеживание состояния. Они могут быть использованы для хранения значений в переменных для последующего использования или сравнения. Использование accessors может быть весьма полезно во многих случаях, но тут мы о них только упомянем.

Assertions так же, как и Accessors оценивают состояние. Но они также позволяют сравнить хранимое значение с ожидаемым. Есть два основных типа “assert (прим. упрощая – это жесткое сравнение – хоть тресни, а должно быть)” и “verify (проверить)”. В Selenium Core неравенство при assert приведет к окончанию теста, в то время как неравенство при сравнении приведет только к записи в лог.
Чтобы получить информативный результат теста, попробуйте использовать методы assert только при крайней необходимости, где неравенство или несоответствие делает продолжение теста бессмысленным.

NB: При тестировании AJAX веб-интерфейсов “WaitFor” методы чрезвычайно удобны для определения того, когда AJAX манипулирует с DOM, после чего вы можете использовать обычные verify / assert. Лучше всего в таких случаях функция waitForCondition(), которая использует Javascript выражения, делающие проверки, в цикле или в течение определенного времени.

Полный список возможных действий, Accessors и Assertions существующих в Selenium Core тут: http://www.openqa.org/selenium-core/reference.html. Список большой, так что при тестировании можно долго развлекаться.

Два последних понятия это локатор элементов и шаблоны. Локатор – это метода для поиска элементов HTML/XML для тестирования. Selenium Core поддерживает поиск с помощью идентификатора и имени элемента, выражений Javascript DOM, XPath, CSS селекторов, и текста ссылки.

Шаблоны это методы для определения текста для поиска. По умолчанию используется метод “glob” (например, «*»/«?»). Также можно использовать точный поиск (полное совпадение). Ну, и где бы мы были без “регулярного выражения”! Несколько примеров я приведу позже.

Реализация пользовательских историй (или – вот одна из подготовленных ранее)

Чтобы не уходить в сторону от темы, будем считать, что пользовательские истории уже реализованы в коде. Необходимо скачать и установить локальную копию. Код написан с использованием Zend Framework), и уже протестирован с PHPUnit и Slenium.
http://downloads.astrumfutura.org/devzone/Acceptance_Testing_Tutorial_Application.tar.bz2 (прим. файл доступен)

Для установки, просто импортируйте /INSTALL.sql в базу данных, скопируйте файл /src/config/config.ini.dist в /src/config.ini и поменяйте настройки под ваше окружение, тоже самое сделайте для /tests/TestConfiguration.php. В этом конфигурационном файле, вы можете изменить значение TESTS_SELENIUM_BROWSER на любой другой вариант (список выше в примере). Baseurl также должен быть изменен и указывать на наше приложение в /WWW каталоге.

Что еще? Предположим, что установка была в корень сайте: зайдите на http://localhost/www/. Вы можете запустить все тесты, которые мы напишем ниже, они расположены тут: http://localhost/tests/AllTests.php

Написание и проведение приёмочных испытаний

Приступим к делу. Я уверен, что достаточно теории на этот момент! Итак, какой был первый приёмочный тест поставленный клиентом?

1. Страница авторизации отображает форму для входа

Наша форма для авторизации находится по адресу “/login” главного файла приложения. Это тот самый URL который нужно открыть в Selenium Core. Во-вторых, наш тест должен проверять наличие регистрационной формы на странице. Мы уже (см. /src/default/views/scripts/login_index.phtml) обозначили форму для входа, и установили уникальный идентификатор “login-form”, по которому мы можем её найти. Также мы уже знаем (из того же шаблона), что должны существовать два поля с идентификаторами “identity” и “password”. Для расширения кругозора мы будем использовать разные шаблоны в локаторе элементов

/** PHPUnit_Extensions_SeleniumTestCase */
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class LoginIndexTest extends PHPUnit_Extensions_SeleniumTestCase
{
protected function setUp()
{
$this->setBrowser(‘*firefox’); // или *iexplore для IE
$this->setBrowserUrl(‘http://localhost/’);
}

public function testLoginFormExists()
{
$this->open(‘http://localhost/login’);

$this->assertElementPresent(“id=login-form”);
$this->assertElementPresent(“dom=document.forms['login-form'].identity”);
$this->assertElementPresent(“dom=document.forms['login-form'].password”);
$this->assertElementPresent(“xpath=//form[@id='login-form']/input[@type='submit']“);
}
}

Если вы скачали готовое приложение, то уже, вероятно запускали этот тест. Полный тест файл находится в файле /tests/AcceptanceTests/UserLoginTest.php. Возможно, вы уже догадываетесь, что добавление браузера и URL напрямую в код приведет к постоянным изменениям – поэтому в этих тестах используется набор констант из файла /tests/TestConfiguration.php.dist.

В примере выше встречается функция assertElementPresent(). Это проверка на наличие определенных элементов HTML / XML. Аргументом является строка, где тип локатора указывается слева от знака равно, а аргумент справа. Я использовал три различных типа. ID проверяет существование элемента с ID равным “login-form”. Наличие двух полей ввода проверяется с помощью выражений Javascript DOM. Наличие кнопки проверяется с помощью XPath.

Достаточно ли этих тестов? Существует риск, что если мы будем делать тесты слишком конкретизированными, то потом потребуется много времени на их редактирование при изменении интерфейса. Тем не менее, кое что еще должно быть проверено. Например, совпадает ли максимальная длина поля (maxlength) с длиной поля VARCHAR в базе данных или превышает его?

$this->assertElementPresent("xpath=//input[@id='identity' and @maxlength='20']");
$this->assertElementPresent("xpath=//input[@id='password' and @maxlength='64']");


2. Отправка правильного сочетания идентификатора пользователя и пароля приводит к успешной авторизации.

Теперь мы добавим тест, который будет отправлять валидные данные пользователя и проверять появилось ли сообщение, определенное в темплейте (см. темлейт login_index.phtml)

public function testValidAuthentication()
{
$this->open('http://localhost/login');

// заполняем форму
$this->type(“dom=document.forms['login-form'].identity”, ‘Padraic’);
$this->type(“dom=document.forms['login-form'].password”, ‘KSkjduj$!hjj*927′);

// отправляем данные
$this->click(“xpath=//form[@id='login-form']/input[@type='submit']“);
$this->waitForPageToLoad(30000); // 30 секунд по умолчанию

// проверяем сообщение
$this->assertTextPresent(‘exact:Welcome, Padraic’);

// проверяем, что нет сообщений об ошибке
$this->assertTextNotPresent(‘*invalid*’);
}

В примере виден ряд новых действий (action) и assertion методов. Первый type().type() имитирует ввод данные пользователем в текстовое поле, и мы используем его здесь, чтобы Selenium Core заполнил регистрационную форму. Действие click() определяет элемент для которого Selenium Core смоделирует нажатие (есть также метод submit() который можно использовать вместо click()). Дополнительный метод waitForPageToLoad() указывает Selenium, что после запроса будет ответ с сервера, и он должен ждать ответа перед тем, как продолжить. Оба PHPUnit и Selenium поддерживают метод clickAndWait(), который объединяет методы click() и waitForPageToLoad(). На момент написания статьи этот метод не работал, видимо будет в «следующем релизе», ну что же подождем и посмотрим…

Также в примере представлены методы assertTextPresent() и assertTextNotPresent(). Оба метода содержат шаблоны. Если вы вспомните, шаблоны используются для поиска текста на странице, используя различные методы, включая поиск glod, регулярные выражения и точное соответствие. В примере используется точное соответствие. Если вы не определите тип шаблона, по умолчанию будет использован “glob”. Хотя это и не плохо, вы, возможно, промахнетесь при поиске строк, которые содержат элементы glob – звездочка или знак вопроса.

3. Она гарантирует быстрое определение будущего поведения, которое отличается от ожидаемого (регрессионное тестирование)


public function testInvalidAuthenticationWithError()
{
$this->open('http://localhost/login');

// заполняем
$this->type(“dom=document.forms['login-form'].identity”, ‘Maugrim’);
$this->type(“dom=document.forms['login-form'].password”, ‘badpass’);

// отсылаем
$this->click(“xpath=//form[@id='login-form']/input[@type='submit']“);
$this->waitForPageToLoad(30000); // 30 secs

// проверяем, что логин не прошел
$this->assertTextNotPresent(‘regexp=Welcome,[a-zA-Z0-9 -_aouieAOUIE]‘);

// проверяем, что ошибка появилась на странице
$this->assertTextPresent(‘*invalid*’);
}

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

4. Форма для логина всегда сопровождается гиперссылкой “Забыли логин или пароль?”.

Это больше изменение теста testLoginFormExists, чем новый тест. Мы просто добавим следующее:
[code]
public function testLoginFormExists()
{
// ...

// проверяем существует ли ссылка
$this->assertElementPresent('link=regexp:^Forgot identity or password?$');
}
[/code]

Когда мы соберем этим тесты вместе, мы, наконец, получи приёмочные тесты достаточные, чтобы сказать, что пользовательская история была реализована и работает. Это, скорее всего, минимальный тесты, так как мы не включили тесты, ориентированные на разработчиков, таких как проверка maxlength, чтобы они соответствовали нашей базе данных, но пока этого достаточно.

Как запускать тесты?

1. Запуск сервера Selenium RC

java -jar selenium-server-standalone.jar

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

2. Запустите файл AllTests.php из каталога /test в браузере.

Если все пойдет хорошо, вы увидите, как трижды браузер открылся и закрылся (можно использовать опцию прокси в Selenium RC, чтобы использовать один и тот же браузер), и результаты будут показаны в браузере.

Заключение

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

Антонио Люпетти (Antonio Lupetti) в своём блоге опубликовал книгу – причёсанный сборник собственных записей по CSS, JS, веб разработке и приёмах для веб. Первая версия книги доступна для скачивания бесплатно.

Хорошо, друзья … Наконец то предварительная версия “Руководства Woork’a” готова. Эта книга – сборник статей, которые я записал в блог в прошлом году. За год “Woork” посетили более 4 миллионов зрителей, и я получил много запросов на распространение печатной версии статей из блога. В течение последних дней я работал над подготовкой первого варианта этого руководства, и вы можете взять его бесплатно.

---

Ok friends… finally a first preview of “The Woork Handbook” is ready to be released. This book is a miscellanea of articles I wrote on my blog in the past year. During the period form January to December 2008 “Woork” has been visited from over 4 millions visitors and I received a lot of requests to distribute a printable version of its contents. In the past days I worked hard to prepare a first version of this handbook and distribute it for free.
-Antonio

Эта книга будет полезна, для освоения многих современных техник и приемов веб программирования. В пояснениях к коду в книге Антонио доступно объясняет как будет представлены разные HTML блоки и как будут меняться их свойства в зависимости от CSS. Что на мой взгляд куда правильнее, чем голая теория по HTML.

Скачать книгу можно тут: The Woork Handbook

Начали копать глубже и оказалось, что с таким поведением сталкнулись не только мы. Причина очень проста. При запуске с параметром -client JVM использует JIT compiler (от Apple) и компилирует классы без оптимизации и профайлинга, а при параемтре -server сначала запускается как интерпритатор и за несколько итераций собирает неободимые профайлы для классов и только потом компилирует их.

Поэтому использовать опцию -server при разработке не стоит, лучше запускать с -client. Так же имеет смысле просчитать сколько времени и при какой нагрузке “прогревается” приложение и в зависимости от результатов оставить всё как есть, либо добавить в код функции, которые позволят пройти этап сбора профайлов быстрее.

Tip #1: JBoss насильно добавляет параметр -server в конфиг.

UPD:
Поговорил еще и оказалось, что практики разработки с опцией -client, и дальнейшее использование с -server не существует (то есть то, что я предложил выше ерунда). Более того, JIT был в версии 1.3. Используется ли сейчас хотспот вместо него я не уверен, но вероятно.

This document is meant to provide web application developers, browser engineers, and information security researchers with a one-stop reference to key security properties of contemporary web browsers. Insufficient understanding of these often poorly-documented characteristics is a major contributing factor to the prevalence of several classes of security vulnerabilities.

Список тезисов с описанием (есть и без него, но, то что они появились более чем за месяц до конференции уже прогресс):

Вёрстка не для роботов / Роман Комаров

С ножом против паровоза / Вадим Макеев

Процесс деплоймента вёрстки – просто, быстро, безопасно / Евгения Фирсова

data:URL как альтернатива CSS Sprites / Николай Мациевский

Стадии загрузки страницы и методы их оптимизации / Николай Мациевский

Механизм разработки приложений для платформ Adobe Flash 8,9 а так же платформы Adobe AIR с единым исходным кодом / Николай Артамонов

Создание казуальных компьютерных игр в вебе: Технологии Popfly Game Creator и Silverlight 2 / Евгений Марченков

Debugging верстки: переходим в операционную / Наталия Арефьева

Комплексный обзор Microsoft Silverlight 2 – платформы для разработки интерактивных Интернет-приложений / Михаил Черномордиков

Internet Explorer 8 изнутри – новые технологии для работы и отдыха / Михаил Черномордиков

Таблицы стилей для печати. Особенности и возможности / Михаил Баранов

Windows Presentation Foundation – архитектура, основные принципы разработки и что нужно знать, начиная свой первый проект / Роман Здебский

Спецификация будущего: инновационные возможности HTML 5 / Нарек Мкртчян

В общем и целом, довольно интересно. Но отсутствует бизнес составляющая. Технологии сами по себе ничего не стоят, особенно в текущий период, когда компании разного профиля сыпяться одна за другой. Довольно странные доклады по Adobe Flash 8 и 9, с учетом, что уже есть версия 10 и она больше является конкурентом для Silverlight 2. По IE8 от Михаила Черномордикова, хотя он и является работником Microsoft, но Алекса Могилевского послушать было бы интереснее – как докладчик Михаил в разы хуже Алекса. А так же по основам WPF и HTML 5 – которые рассчитаны больше на новичков, которые не знают о Total Training for Microsoft WPF (наврят ли кто то может лучше рассказать о том что такое WPF и как с ним работать) и о видео на w3c по HTML5, соответственно.

Стоимость участия в конференции “РИТ: Клиентские технологии”:

• 7 000 рублей до декабря месяца,
• с 1-го декабря стоимость участия составит – 9 000 рублей.
• Для членов клуба скидка составит 1 000 рублей

для Гуру (по факту – докладчиков) скидка 50%