Сразу хочу предупредить, что данный код писался для собственного удовольствия и практического применения не имеет. Авто-тест открывает в браузере GitHub репозиторий самого себя, находит свой код на странице — и запускает его. Для написания авто-теста использовался PHPUnit, phpunit-selenium (Webdriver), и велосипед самописный «микро-фреймворк». Для ознакомления с реализацией, возможностями и скринкастом моего велосипеда прошу под кат.
Как показала практика, львиную долю времени при написании авто-тестов занимает написание и поддержка локаторов для элементов страниц, в каком бы виде они не были у вас представлены: XPath, CSS selector, etc. Почему бы не позволить добавлять, редактировать и удалять их прямо во время запуска теста? С этой идеи и началась разработка моего авто-фреймворка.
Умеет быть Объектно-Ориентированным. Не хочу сказать, что это лучшая парадигма в программировании, но как показывает мой опыт, ООП подход неплохо себя зарекомендовал. Напротив, процедурный код часто приходилось переписывать с нуля из-за невозможности дальнейшей поддержки. В моем велосипеде каждая страница тестируемого сайта — класс, имеющий те и только те методы, которые нужны на данной странице.
Покрыт unit-тестами. А также позволяет покрывать unit-тестами добавляемые классы страниц. Фреймворк старается следовать принципам SOLID, и класс страницы содержит тяжелый класс сессии (PHPUnit_Extensions_Selenium2TestCase) лишь как внешнюю зависимость.
Имеет все «плюшки» PHPUnit фреймворка. Нужен метод setUp() или tearDown()? — Пожалуйста. Нужен метод setUpBeforeClass() или tearDownAfterClass()? — Пожалуйста (в этом случае используется статический метод для создания объекта сессии). В любом из этих методов мы можем продолжать обращаться к selenium серверу.
Использует Composer для установки компонент. Вряд ли это можно преподносить как «фишку» (это уже мейнстрим). Но все же приятно в одну комманду иметь подготовленное для авто-тестов окружение.
Ну и самая главная фича моего маленького фреймворка — возможность редактировать локаторы в runtime. Нужно лишь у объекта страницы вызвать метод debug(). Авто-тест приостанавливает дальнейшее выполнение тест-кейса, открывает popup, позволяющий редактировать локаторы. Все изменения тут же попадают в файловую систему в сериализированном виде (предполагается, что в эти файлы нет нужды заглядывать). При закрытии popup окна тест автоматически продолжает свое выполнение. В общем, лучше один раз увидеть…
Тех, кто не поленится склонить проект прошу обратить внимание, сколь мало усилий и изменений потребовалось, чтоб написать тест-кейс для двух страниц на GitHub. Файлы в папке var были сгенерированы с помощью описанной выше фишки фреймворка.
При написании пришлось столкнуться с тем, что иногда при нажатии на папку/файл навечно зависает лоадер — и не подгружается контент выбранного элемента (для этого были добавлены try-catch блоки в код). Также на Firefox в данном тест-кейсе вылетает исключение «waiting for evaluate.js load failed» (на других сайтах, кроме GitHub, данной проблемы не было). Есть подозрение, что это баг Firefox драйвера, поскольку в Chrome все нормально.
Сам тест-кейс определяет свой относительный путь в репозитории, идет по этому пути на GitHub, открывает raw (для упрощения) исходник самого себя, определяет, с какой по какую строчку нужно себя запустить, и запускает с помощью eval().
Четких планов по поводу дальнейшего развития «микро-фреймворка» нету. Как я уже писал выше, код писался лишь для собственного удовольствия. Но предложения, конструктивная критика и push-request-ы будут обязательно рассмотрены.
Немного предыстории
Как показала практика, львиную долю времени при написании авто-тестов занимает написание и поддержка локаторов для элементов страниц, в каком бы виде они не были у вас представлены: XPath, CSS selector, etc. Почему бы не позволить добавлять, редактировать и удалять их прямо во время запуска теста? С этой идеи и началась разработка моего авто-фреймворка.
Что мой фреймворк умеет?
Умеет быть Объектно-Ориентированным. Не хочу сказать, что это лучшая парадигма в программировании, но как показывает мой опыт, ООП подход неплохо себя зарекомендовал. Напротив, процедурный код часто приходилось переписывать с нуля из-за невозможности дальнейшей поддержки. В моем велосипеде каждая страница тестируемого сайта — класс, имеющий те и только те методы, которые нужны на данной странице.
Покрыт unit-тестами. А также позволяет покрывать unit-тестами добавляемые классы страниц. Фреймворк старается следовать принципам SOLID, и класс страницы содержит тяжелый класс сессии (PHPUnit_Extensions_Selenium2TestCase) лишь как внешнюю зависимость.
Имеет все «плюшки» PHPUnit фреймворка. Нужен метод setUp() или tearDown()? — Пожалуйста. Нужен метод setUpBeforeClass() или tearDownAfterClass()? — Пожалуйста (в этом случае используется статический метод для создания объекта сессии). В любом из этих методов мы можем продолжать обращаться к selenium серверу.
Использует Composer для установки компонент. Вряд ли это можно преподносить как «фишку» (это уже мейнстрим). Но все же приятно в одну комманду иметь подготовленное для авто-тестов окружение.
Ну и самая главная фича моего маленького фреймворка — возможность редактировать локаторы в runtime. Нужно лишь у объекта страницы вызвать метод debug(). Авто-тест приостанавливает дальнейшее выполнение тест-кейса, открывает popup, позволяющий редактировать локаторы. Все изменения тут же попадают в файловую систему в сериализированном виде (предполагается, что в эти файлы нет нужды заглядывать). При закрытии popup окна тест автоматически продолжает свое выполнение. В общем, лучше один раз увидеть…
Пару слов о рекурсии...
Тех, кто не поленится склонить проект прошу обратить внимание, сколь мало усилий и изменений потребовалось, чтоб написать тест-кейс для двух страниц на GitHub. Файлы в папке var были сгенерированы с помощью описанной выше фишки фреймворка.
При написании пришлось столкнуться с тем, что иногда при нажатии на папку/файл навечно зависает лоадер — и не подгружается контент выбранного элемента (для этого были добавлены try-catch блоки в код). Также на Firefox в данном тест-кейсе вылетает исключение «waiting for evaluate.js load failed» (на других сайтах, кроме GitHub, данной проблемы не было). Есть подозрение, что это баг Firefox драйвера, поскольку в Chrome все нормально.
Сам тест-кейс определяет свой относительный путь в репозитории, идет по этому пути на GitHub, открывает raw (для упрощения) исходник самого себя, определяет, с какой по какую строчку нужно себя запустить, и запускает с помощью eval().
Послесловие
Четких планов по поводу дальнейшего развития «микро-фреймворка» нету. Как я уже писал выше, код писался лишь для собственного удовольствия. Но предложения, конструктивная критика и push-request-ы будут обязательно рассмотрены.