Всем привет. Данная статья посвящается методологии Разработки через тестирование (TDD) в применении c JavaScript.
Напишу лишь вкратце о методологии TDD, более подробную информацию можно почерпнуть из ссылки выше.

Разработка через тестирование подразумевает, что перед написанием кода необходимо:

• создать тест, который будет тестировать несуществующий код, тест соответственно не пройдет
• написать код и убедиться, что тест прошел
• почистить код
• повторить

Наткнулся вчера на этот инструмент и не смог пройти мимо, провел ночь за написанием тестов, а теперь хочу поделиться находкой. QUnit — это библиотека от разработчиков jQuery, позволяющая писать unit-тесты для кода на javascript. Удобна в использовании, ничего лишнего, осваивается за 20 минут, выгода от применения — колоссальная.

Самым нетерпеливым сразу ссылки:
Официальная документация на сайте jquery: docs.jquery.com/QUnit
Реальные примеры тестов (для модулей jquery): view.jquery.com/trunk/jquery/test/unit
Руководство для начинающих (англ): www.swift-lizard.com/2009/11/24/test-driven-development-with-jquery-qunit
Система распределенного тестирования (гениально и просто): testswarm.com

Под катом информация о преимуществах юнит-тестирования применительно к js и разбор возможностей библиотеки на примерах.

Каждый, кто всерьез занимался разработкой на Ruby, знает про замечательный гем Cucumber. Вкратце — это библиотека для автоматизированного тестирования, заточенная под BDD. Подробнее можно почитать в топике хабраюзера dapi, а еще лучше посмотреть подкаст от Райна Бэйтса. Основная прелесть «огурца» состоит в том, что он позволяет писать тесты на понятном человеку языке, и даже не обязательно английском. Выглядит это так:

Feature: Addition 
  In order to avoid silly mistakes 
  As a math idiot 
  I want to be told the sum of two numbers 

  Scenario: Add two numbers 
    Given I have entered 50 into the calculator
      And I have entered 70 into the calculator
     When I press add
     Then The result should be 120 on the scree

Благодаря Cucumber я подсел на BDD на рельсах. Но вот на PHP, с которым приходится работать основную часть времени, отношения с BDD как-то не сложились. И в первую очередь из-за отсутствия достойного инструментария. Но однажды судьба завела меня на страницу библиотеки Behat (написанной, кстати говоря, хабраюзером everzet). И на меня свалилось счастье…

Кэмерон Адамс, скрывающийся под псевдонимом The Man in Blue, решил показать миру красоту связи между видеорядом и музыкой, сделав из своей избранной дискографии Daft Punk один большой мэшап.

Интересно то, что плеер и визуализация сделаны на HTML5, CSS3, jQuery и Canvas.

Смотреть мэшап рекомендуется в Chrome, а особенно любопытным можно почитать комментарии автора.

По сути Synergy является кумулятивным Open Source расширением Spree, ориентированным на создание интернет-магазинов в России.
Миссия проекта состоит в том, чтобы предоставить весь необходимый фунционал, специфичный для российских интернет-магазинов, а также упростить интеграцию рекомендуемых расширений.

В свою очередь Spree – это полнофункциональная платформа электронной коммерции, работающая на фреймворке Ruby on Rails 3. Она создана с целью упростить разработку интернет-магазинов путем включения в нее всего базового функционала, необходимого разработчикам.

Ну что, начнем? Давайте напишем какой-нибудь небольшой, но законченный проект. Выделим на это ровно 1 час. Предлагайте название. Книжный магазин? Если других идей нет, то будем писать блог :)

Разрешение экрана в наши дни колеблется от 320px (iPhone) до 2560px (большие мониторы) или даже выше. Пользователи больше не просматривают сайты только на настольных компьютерах. Теперь пользователи используют мобильные телефоны, небольшие ноутбуки, планшетные устройства, такие как iPad или Playbook для доступа в интернет. Поэтому, традиционный дизайн с фиксированной шириной больше не работает. Дизайн должен быть адаптивным. Структура должна автоматически изменяться с учетом всех разрешений дисплеев. Эта статья покажет вам как создавать кросс-браузерный адаптивный дизайн при помощи HTML5 и CSS3 media queries.

Platform as a Service (PaaS) — это не самая тривиальная вещь для создания, развертывания и поддержки: для начала, приходится проделать немалую работу для управления всеми сервисами изнутри, затем предстоит продумать и реализовать хороший интерфейс, и, в конце-концов, сервис нужно продать и умело его поддерживать. Не удивительно, что инвестиции для создания таких сервисов, могут позволить себе только несколько зажиточных игроков на IT-рынке.

Поэтому было вдвойне интересно наблюдать, как VMware разворачивают сервис CloudFoundry, да еще и с открытым кодом (честно, вот github аккаунт)! Полноценная PaaS, которую они так же предлагают использовать как хостинг, доступна так же каждому, для запуска в собственной компании или датацентре — теперь вы можете запустить «мини Heroku», или «облако EngineYard» на собственных серверах! Но в сторону маркетинг, гораздо интереснее взглянуть под капот этого проекта, ведь он полностью организован на Ruby.

jQuery однозначно стал стандартом в индустрии веб-дева. Есть много отличных js-фреймворков, которые заслуживают внимания, но jQuery поразил всех своей лёгкостью, изящностью, магией. Люди пишут с использованием jQuery, люди пишут плагины для jQuery, люди даже пишут статьи про jQuery, но мало кто знает (особенно из новичков), КАК устроен jQuery.

В этой статье проведем небольшой экскурс во внутренности этого фреймворка и разберем, что внутри.
Статья рассчитана на базовые знания Javascript. Задумайтесь и, если вы знаете, как написать клон jQuery, то, скорее всего, вы тут не найдёте ничего нового. Остальным — добро пожаловать под кат

Почти год назад я опубликовал статью о микрофреймворке под названием 'fat-free', написанном на PHP. Тогда этот фреймворк и сама статья вызвали некоторый интерес, поэтому я решил сделать обзор еще одного PHP микрофреймворка в стиле популярного Sinatra — Silex project.

Созданный в известной в РНР кругах Sensio Labs, не менее известным Fabien Potencier — автором одного из самых популярных на сегодня PHP фреймворков — Symfony, Silex является облегченной версией ожидаемого армией фанатов (к которым осмелюсь отнести и себя) Symfony2.

Для своей работы Silex использует ключевые компоненты Symfony2 в связке с несложной реализацией шаблона проектирования “Внедрение зависимостей” в виде сервис-контейнера Pimple, который позволяет максимально просто отделить логические части кода друг от друга — сделать их независимыми.

Как и у Symfony2 — у Silex интуитивно понятный API, что делает процесс разработки достаточно приятным и позволяет практически в несколько шагов добавлять свой функционал в сам фреймворк.

Введение

Вышла уже четвертая альфа jQuery Mobile, сделавшая фреймворк более-менее стабильным и удобным в использовании. Единственное, чего пока сильно не хватает — хорошей документации. Например, сейчас там описан только стандартный workflow показывающий переходы по JQM страницам. Но что делать, если вы хотите загружать данные динамически?
^{Статья подразумевает, что у вас есть хотя бы небольшие представления о том, что такое javascript, как работает jQuery и JQM.}

Ну собссно сабж, что здесь сказать еще :)



ПОЛНЫЙ обзор под катом :)

Я только что получил следующее письмо, которым хочу поделиться и ответить на него публично.

«Я не использую эту методологию (TDD) из-за того, что главный для меня вопрос остается без ответа. Я знаю, что использование TDD уменьшает количество багов, но что насчет времени, необходимого при работе по этой методологии?
Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD — уменьшается, увеличивается или остается неизменным.
Надеюсь, вы сможете ответить, так как TDD и BDD меня очень интересуют.»

Теория

Для начала, давайте разберемся, что же такое Behavior Driven Development(в дальнейшем BDD) и чем данная техника отличается от Test-Driven Development(в дальнейшем TDD)

Разрабо́тка че́рез тести́рование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.

Без использования unit-тестов и TDD очень легко выстрелить себе в ногу. С тестами и TDD сделать это намного сложнее, но если у вас получится, вы останетесь без ноги.

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

В этой статье я постараюсь объяснить о чем, собственно, разговор. Для чего нужно TDD и как его аккуратно использовать.

Что такое TDD в двух словах? — это написание разработчиком тестов до реализации функциональности.
По совету Роя Ошерова разобьем вопрос применимости TDD на два:

• Зачем писать тесты?
• Зачем писать тесты до реализации?

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

Я решил взять противника не умением, а числом, и поэтому вот вам 19 причин, по которым писать тесты все-таки стоит (в хронологическом порядке). Итак, тесты

Один раз я посмотрел на свой холодильник и не нашел свободного места от магнитиков привезенных с разных городов и стран. Нахлынули воспоминания, но было их куда меньше, чем кажется. Ночевка в холодной палатке в поле, забитый соплеменниками 5* UAI, стремный дребезжащий самолет Украинских авиалиний. Это часть отдыха активного. На это ушло очень много денег и не всегда они вернулись сторицей.

Сегодня мир стал меньше – Ближний Восток кипит, Турция разжирела из-за перешедших им туристов, а Крым – хм-м-м, это Крым.

Тогда мне и моему партнеру пришла идея – хей, а ведь на диване дома порой бывает не хуже, чем на шезлонге тропического пляжа! Так мы создали идеалистическую идею агентства "Диван".

Большинство людей не умеют писать unit-тесты. И даже те, кто применяет модульные тесты в ежедневной разработке, зачастую признают, что получившиеся тесты иногда не очень эффективны по определенным причинам. К этой категории людей я могу отнести и себя. В первую очередь, такой «причиной» является некоторая появляющаяся «инертность» кода, заключающаяся в том, что если требуется немного изменить какой-то ключевой алгоритм, добавить пару строчек кода, то при этом «падают» ~100 модульных тестов и приходится тратить продолжительное время на то чтобы заставить их работать вновь. Итак, приступим к «хорошим рекомендациям» при написании автоматических модульных тестов. Нет, я не буду капитаном очевидностью, в очередной раз описывая популярный стиль написания тестов под названием AAA (Arange-Act-Assert). Зато попытаюсь объяснить, чем отличается Mock от Stub-а и что далеко не все тестовые объекты — «моки».