Я надеюсь, что как грамотный разрабочик, вы имеете представление о unit-тестировании и сделаете себе в голове пару мысленных отметок о том, чего надо избегать при написании тестов. Знакомьтесь:

Лжец (The Liar)

Unit-тест, который успешно выполняет все кейсы и выглядит работающим правильно, однако при более детальном рассмотрении обнаруживается, что он на самом деле не тестирует то, что должен.

Всем привет! Хабраюзер shai_xylyd написал статью про аспекты тестирования, где им были рассмотрены некоторые понятия и ценности TDD. В частности, он упомянул очень интересный способ создания первичных юнит-тестов — когда функциональный код пишется совместно с кодом юнит-теста, чем меня очень заинтриговал.

Дело в том, что я (как программист), нахожусь в состоянии переходного процесса между «классической» разработкой и разработкой test-driven, поэтому всякими способами ищу возможности упростить и сделать более естественной последнюю. После пары приседаний, сразу включиться в методику shai_xylyd не сумел. Начал переписку с автором статьи, где он натолкнул меня на мысль подойти к решению с математической точки зрения. Идея в том, чтобы воспользоваться функциональным пространством среды программирования и «разложить» написание юнит-теста на составляющие. После чего сделать выводы.

Язык PHP очень легок для изучения. Это, а так же обилие литературы «Освой _что_угодно_ за 24 часа» породило большое количество, мягко говоря, некачественного кода. Как следствие, рано или поздно любой программист, который выходит за рамки создания гостевой книги или сайта-визитки сталкивается с вопросом: «а если я здесь немножко добавлю, все остальное не ляжет?» Дать ответ на этот вопрос и на многие другие может юнит-тестирование.

В самом начале хочется оговориться — здесь речь не будет идти о TDD и методологиях разработки ПО. В данной статье я попробую показать начинающему PHP-разработчику основы использования модульного тестирования на базе фреймворка PHPUnit

Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

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

Рекомендация первая: забудьте про блочную верстку. Весь лэйаут должен быть на таблицах. При этом, без крайней необходимости — их тоже лучше не использовать. Также следует выкинуть из головы представления о семантике, сокращенных css-правилах, валидации, плавающих блоках — и прочее. Самый распространенный в РФ почтовый сервис на данный момент (mail.ru) вообще не понимает стили (css). Любые тэги/атрибуты style заменяются на xstyle и не работают. Вообще все.

Так что, фактически, при вёрстке html для почтовой рассылки надо мысленно переместиться в 90-ые годы прошлого века и смело использовать все распространенные приёмы того времени.

Для тех, кто с ними не знаком (как я был) — напомню:

Многие знают о механизме Event-Dispatcher-Listener'ов, реализованному во многих языках программирования. Я же создам подобный механизм не для Event'ов, а для любого метода объекта JavaScript — Object.
Я не претендую на оригинальность, нет. Основная цель статьи — рассмотреть интересные механизмы прототипирования в JavaScript, создание декораторов и, собственно, постараться хоть немного раскрыть мощь и гибкость это чудесного языка, который так часто обижают и недооценивают.

UPD1: краткое содержание:
1. Создание декоратора на JavaScript
2. Создание механизма Function call listener с помощью декораторов

UPD2: от 09.06.2009
В конце статьи я добавил раздел Update: Decorator Mark II. В нём — исправления и улучшения (я не перекраивал всю статью из-за этого)

Итак, первый (и, надеюсь, не последний) рецепт в моей поваренной книге JavaScript.