В процессе разработки современных JS приложений особое место уделяется тестированию. Test Coverage на сегодня является чуть ли не основной метрикой качества JS кода.
В последнее время появилось огромное количество фреймворков которые решают задачи тестирования: jest, mocha, sinon, chai, jasmine, список можно долго продолжать долго, но даже имея такую свободу выбора инструментов для написания тестов остаются кейсы которые сложно протестировать.
О том как протестировать то что в общем может быть untestable пойдет речь далее.
Читать дальше →
![](https://habrastorage.org/files/f3e/2f7/79d/f3e2f779d73e4e12966608d913977eb9.jpg)
Runkit 1.0.4 для PHP выпущен!
Поздравляю всех пользователей Runkit с новым долгожданным мега-релизом! Если вы постоянно используете Runkit и хорошо знакомы с его возможностями, историей и развитием, то можете сразу переходить к описанию изменений релиза 1.0.4. В любом случае предлагаю прочесть статью целиком.
Читать дальше →
... код, конечно же,
! Сначала создаю контейнеры ...
Настройка локально
Начало: habrahabr.ru/post/267441
В этой статье я предполагаю, что служба docker запущена на той же машине, на которой выполняются команды, и у процесса есть доступ на чтение к текущей папке. Еще я подразумеваю, что вы умеете настраивать связку PHP-FPM и Nginx.
Беру образы Nginx и PHP 7.
~$ docker pull nginx
...
~$ docker pull php:7-fpm
Status: Downloaded newer image for php:7-fpm
Теперь у меня есть два чужих класса, которые надо связать вместе через внедрение зависимостей. Самый простой способ добавлять зависимости в чужой код, конечно же, monkeypatching! Сначала создаю контейнеры. Помню о второй сложности программирования — даю контейнерам вразумительные имена, они будут нужны, чтобы контейнеры могли взаимодействовать между собой.
Читать дальше →
![SugarJS logo](http://habrastorage.org/getpro/habr/post_images/171/7ab/548/1717ab548cc123ddb67822d9464b9a81.png)
В комментариях к посту про Underscore/Lo-Dash я упомянул, что среди библиотек, расширяющих стандартную библиотеку JavaScript, я предпочитаю SugarJS, который, в отличие от большинства аналогов, работает через расширение нативных объектов.
Это вызвало горячую дискуссию о том, допустимо ли расширять нативные объекты. Меня очень удивило, что практически все высказавшиеся выступили против.
Это побудило меня перевести манифест SugarJS по этому вопросу. По всей видимости, автору этой библиотеки приходилось очень часто слышать подобные нападки. Поэтому он очень взвешенно и достаточно непредвзято прокомментировал каждую из них.
В этом материале разбираются подводные камни JavaScript, известные и не очень, а также предлагаются методы защиты. Поэтому я думаю, что статья будет интересна и полезна любому JS-разработчику, независимо от его отношения к проблеме расширения нативных объектов.
Передаю слово Andrew Plummer.
Итак, Sugar — библиотека, которая модифицирует нативные объекты JavaScript. Подождите, разве это не во зло? — спросите вы, — вы что, не извлекли урок из горького опыта Prototype?
По этому поводу существует много заблуждений. Sugar избегает подводные камни, о которые спотыкался Prototype, и фундаментально отличается по своей сути. Однако этот выбор — не без последствий. Ниже разобраны потенциальные проблемы, вызываемые изменением нативных объектов, и изложена позиция Sugar насчет каждой из них:
- Модификация объектов среды
- Функции как перечисляемые свойства
- Переопределение свойств
- Конфликты в глобальном пространстве имен
- Допущения насчет отсутствия свойств
- Следование спецификации
Читать дальше →