Фреймворк для автоматического тестирования веб-приложений на PHP — Codeception живет и развивается. Но в этот раз вместо скупой порции новостей я бы хотел представить вам первый скринкаст в котором показаны азы работы с Codeception. Если вы только читали про Codeception, то вам обязательно стоит взглянуть на него в действии. Ну а если не читали, но у вас есть веб-сайт, который бы вы хотели протестировать — тоже взгляните.

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

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

Задача которую нужно было решать — каким образом хранить, искать, модифицировать информацию о последовательности событий при следующих условиях:

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

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

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

Везде, где я буду говорить про автоматизацию тестирования, речь будет идти про тестирование интерфейса с подключением к внешним ресурсам (БД, файловая система, сервисы и т.п.).

Привет, Хабрасообщество!
По следам недавно прошедшей конференции DevConf 2012 хочу поделиться записями из своего блокнота, которые показались лично мне наиболее интересными и полезными. Возможно, кому-то все это хорошо известно. Поскольку доклады шли одновременно в нескольких залах, то все их посетить было невозможно, поэтому ваши дополнения с удовольствием почитаю в комментариях.
Темы, которые прежде всего интересовали меня, это:
— развертывание системы и непрерывная интеграция (Continuous Integration)
— PHP 5.4, PHPUnit, Yii
— тестирование в javascript

PHP очень популярный язык программирования, но тестирование в нем, это скорее прерогатива экспертов, а не жизненная необходимость. Неужели это от того, что PHP-разработчики поголовно быдло-кодеры? Я считаю, что нет. Скорее всё от того, что системы тестирования порой излишне усложнены. А тесты, наоборот, должны были предельно просты: легко читаться, писаться, отлаживаться, и конечно же, быстро выполняться. Мое виденье того как это можно воплотить в PHP вылилось в проект под названием Codeception.

С ним тесты для ваших веб-приложений могут выглядеть так:

<?php
$I = new TestGuy($scenario);
$I->wantTo('create new blog post');
$I->amOnPage('/blog/posts');
$I->click('Create new post');
$I->fillField('Title','Codeception, a new way of testing!');
$I->fillField('Text','Codeception is new PHP full-stack testing framework.');
$I->click('Send');
$I->see('Congratulations, your post is successfully created!');

Согласитесь, такой тест понятен без дополнительных комментариев.
А теперь самое интересное: этот код без всяких изменений может быть выполнен как функциональный тест в фреймворках symfony, Symfony2,Zend Framework, а также в браузерном эмуляторе Goutte и даже через Selenium. Таким образом, вам предлагается единый интерфейс для написания функциональных тестов практически для любого сайта.

Данная заметка призвана пролить свет на использование соли при хешировании пароля. Если посмотреть в комментарии к этому топику habrahabr.ru/post/145642, то возникает подозрение, что некоторые люди неправильно понимают предназначение соли. На примерах постараюсь показать, для чего используется этот механизм. Всех заинтересовавшихся прошу под кат.

«Какой препроцессорный язык стоит использовать для CSS?» является очень актуальным вопросом в последнее время. Несколько раз меня спрашивали об этом лично, и казалось бы, каждые пару дней этот вопрос поднимался в сети. Очень приятно что беседа перешла из темы о плюсах и минусах препроцессинга к обсуждению какой же язык является лучшим. За дело!

Если быть кратким: SASS.

Немного развернутый ответ: SASS лучше по всем пунктам, но если вы уже счастливы с LESS — это круто, по крайней мере вы уже упростили себе жизнь используя препроцессинг.

Развернутый ответ: ниже

Когда начинающие системные администраторы сталкиваются с необходимостью настройки почтового сервера, они могут испытывать затруднения связанные с пониманием основных принципов работы почтового механизма. Чтобы внести ясность, я подготовил эту статью, основанную на освещении тех моментов, которые были мне в свое время непонятны. Статья подойдет также разработчикам ПО, которым надо быстро поднять почтовый сервер и протестировать свое приложение.

После недавних событий по массовому открытию новых облачных хранилищ ваш покорный слуга задался вопросом: «Какие есть сейчас хранилища и куда можно запихнуть свои жизненно необходимые файлы?»
Некоторое время рысканья по хабру/гуглу и прочим конторам привело к следующему списку хранилищ:

Baidu, Bitcasa, Box.net, Dropbox, Google Drive, Microsoft SkyDrive, SpiderOak, Wuala, Яндекс.Диск

В самом конце статьи ищите сравнительную таблицу.

 

Чем дальше в лес, тем толще партизаны. Нет, не так. Чем старше веб, тем больше джаваскрипта

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

Собрался духом и таки описал свой почти 3-х летний опыт использования NetBeans для web-разработки. Статья получилось обширной, и, надеюсь полезной.

Большинство разработчиков проводят львиную часть своего времени в среде разработки. Но далеко не все используют хотя бы половину возможностей, которые есть в IDE, тем самым делая свою работу местами скучной, монотонной, медленной… Не, это не наш путь! Свой основной рабочий инструмент нужно использовать на полную, выжимать из него максимум, и всё самое неинтересное, все часто повторяющиеся действия перекидывать на плечи программы.

Cуществует уже несколько десятков JavaScript-фреймворков для построения сложных приложений в браузере. Чтобы сравнить их между собой и выбрать наиболее подходящий, примитивного примера вроде классического «Hello, world» явно недостаточно. Более сложные и реалистичные примеры программ в книгах и документации каждого фреймворка могут сильно отличаться, и сравнивать их между собой затруднительно. Проект TodoMVC решает именно эту проблему. Это набор примеров реализации одного и того же простого, но вполне законченного веб-приложения с использованием разных фреймворков + эталонный пример на чистом JavaScript.

Приложение TodoMVC — это список дел. Дела можно добавлять, помечать как выполненные и удалять. Список должен сохраняться в локальном хранилище браузера. Приложение должно по возможности использовать стандартный шаблон HTML и CSS. Вот подробная спецификация приложения.

Когда-то давно, когда горы были выше, а деревья зеленее, в браузерах поиск в адресной строке работал так, как это было правильно: он использовал функцию Google I'm Feeling Lucky. Вы могли легко вводить «хабр» вместо «habrahabr.ru», вводя «Сан-Франциско», вы сразу же попадали на сайт этого города в Википедии (ведь туда вы и хотели, правда?), а фраза «php in_array» моментально перекидывала вас на документацию по этой функции, в синтаксисе которой вы в очередной раз забыли, needle или haystack идет первым.

Но потом Гугл понял, что $110 млн в год, которые они теряют из-за того, что вам никто не показал рекламу на эти запросы — это непозволительно много, и больше браузеры по умолчанию не хотят демонстрировать нам всю телепатическую магию поиска I'm Feeling Lucky, а вместо этого демонстрируют промежуточное звено поисковой страницы, на которой вы все равно как всегда сразу же нажимаете на первую ссылку (ведь где еще может быть Википедия?), но зато посмотрели рекламу и добросовестно уменьшили рекламодателю CTR.

В разработке проекта зачастую принимают участие разработчики разного уровня. Это приводит к тому, что нет строгого формата написания кода. За качеством кода на проекте приходится постоянно следить старшим разработчикам и это отнимает у них кучу времени.

Для того чтобы наказать говнокодеров облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это PEAR и PHP Code Sniffer.

От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Все дела сделаны и теперь есть время черкануть пару строк об автоматизации тестирования…

Доброго времени суток!
Как известно, утро добрым не бывает, но аудитория хабрахабра знает, что сон можно обхитрить, и проснуться полным сил для нового дня. Выделю три группы высыпающихся людей, кто-то просто много спит, другие правильно готовятся ко сну, третьи пользуются хитрыми будильниками. С недавних пор, я переехал из разряда не высыпающихся в группы пользователей будильников с фазами сна. На переезд было затрачено минимум усилий, потребовалась лишь бесплатная программа для моего android смартфона.

Upd. Владельцы iOS и Windows Phone 7.5 не остались забытыми.

PhantomJS — это сборка движка WebKit без графического интерфейса, позволяющая в режиме консоли загружать веб-страницу, выполнять JavaScript, полноценно работать с DOM, Canvas и SVG. Одним из главных заявленных применений PhantomJS является автоматизированное функциональное тестирование пользовательского интерфейса. PhantomJS имеет интеграцию с различными фреймворками для тестирования JavaScript и веб-страниц. Посмотрим, что можно сделать на базе стандартного функционала PhantomJS, чтобы протестировать отдельный компонент и целое приложение, написанное на ExtJS/Sencha. В этой статье я приведу некоторую простейшую заготовку для тестировочного фреймворка, иллюстрирующую подход к тестированию кода, основанного на сторонней JavaScript-библиотеке. Весь код, представленный в статье, доступен на GitHub.

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



Картинка кликабельна.

PS: Оригинал на английском здесь. Переводил на русский — не я.