Как стать автором
Обновить

Комментарии 26

А как продвигается работа в направлении поддержки PHP7? Релиз уже близко :)
Владислав, спасибо за вопрос. Дело вот в чем, чтобы Runkit завелся под PHP7, нужно проделать большую работу, на длительное время сделать это основной своей деятельностью. Но надо же при этом что-то есть. Так что вся надежда на пожертвования пользователей: если это будут нормальные достойные суммы и, главное, если таких пожертвований будет много, то Runkit под PHP7 быстро станет реальностью.

Я сделал приблизительные оценки этой задачи по времени и по стоимости – числа получаются большие, т.е. либо желающих получить Runkit для PHP7 должно быть много, либо среди них должны быть щедрые желающие, возможно, компании.
НЛО прилетело и опубликовало эту надпись здесь
Предполагаю, что для модульного тестирования и песочниц. И еще для обновления кода на лету. Кроме того, программы на PHP5 очень легко переедут на PHP7.
Он нужен, чтобы заткнуть архитектурные проблемы старого и/или неподдерживаемого кода.

Я бы не был столь категоричен. RunKit используется по-разному. И аналога многим его возможностям в PHP7 нет.
Ух ты, он живой :)
Отличная работа, спасибо.
Пользуйтесь на здоровье! :)
Боже мой, этим даже пользуются и ждут релиза? Я бы за использование этого казнил бы на месте! Это же как людям не хватало кривых рук, что они придумали костыли в рантайме делать?
В продакшен-системе его использовать и правда не стоит, а вот для юнит-тестов и создания моков без необходимости использовать DI это расширение очень даже ничего.
Вы ж учтите что используя это в юнит тестах, можно что-то «изменить» так, что тесты будут проходить, а вот собственно ошибки останутся. Поэтому теоретически да, можно использовать в юнит тестировании, но на практике я бы и там не решился бы это использовать. Просто сделать метод видимым и протестировать его можно и без этой библиотеки.
Если не заменять заглушками тестируемые функции, то ошибки никуда не скроются, все будет хорошо. А как без такого инструмента тестировать поведение методов, не поддерживающих dependency injection?
Есть куда более простые альтернативы для тестирования такого кода без сторонних расширений PHP.
Например AspeckMock.
Да, AspectMock может, если у вас PHP 5.4+ и вы никогда не делаете заглушки для функций.
На мой взгляд, заглушки для функций (в том числе для функций, встроенных в PHP) в тестах бывают очень полезны.
Что значит заглушки для функций? AspectMock как раз и позволяет мокать любые функции.
В том числе стандартные функции PHP пруф
Простите, недооценил AspectMock.

Тут, как говорится, на вкус на цвет. Можно по-настоящему заменять методы и функции в рантайме на заглушки, а можно вместо каждого include() сначала делать file_get_contents(), потом preg_replace(), оборачивающий всевозможные места в коде (вызовы функций, тела методов и т.п.) в if'ы с заглушками, а потом получившийся код eval()'ить, как это примерно и происходит в Go-AOP, на основе которого работает AspectMock.

В 2006-м я использовал и оба подхода параллельно, сейчас мне больше нравится Runkit.
В целом вы правы это на вкус и цвет.
Но у runkit есть существенный минус в том что это отдельное расширение для PHP и его нужно ставить отдельно.
И всего пол года назад я его поставить и вовсе не смог, а точнее не смог использовать, по причине сегфолтов. У AspectMock такого минуса нет.

К слову не «как это происходит в Go-AOP», а собственно AspeckMock на Go-AOP и построен =)
Полгода назад релиза 1.0.4 еще не было и PHP 5.5 и 5.6 не поддерживались. Надеюсь, сейчас у вас никаких сегфолтов Runkit не вызывает. Если что-то не работает — ставьте issue на github'е, починю.
В Go-AOP для стандартных функций не используется eval, там фишка с namespace
А кстати, почему бы не использовать в продакшене? Я знаю один высоконагруженный проект, в котором это делали еще в 2006-2007-м.
Есть у меня мнение, что у этого высоконагруженного проекта был плохой код. Не нужен runkit на продакшене. Да даже в тестах, опять-таки он нужен, когда код плох.
Плохой код, к сожалению, не редкость. С другой стороны, проектирование архитектуры кода с точки зрения тестируемости может идти вразрез с проектированием с точки зрения эффективности и быстроты реализации.
Дима, разве в этом высоконагруженном проекте runkit не только для тестов использовался?
В том проекте он не использовался в тестах ;)
Если глючит сторонний код (библиотеки, каркаса или расширения), то почему бы и не «починить», то есть подменить его таким макаром? Всё лучше чем ждать у моря погоды.
Ситуации, когда нельзя или нет смысла править сторонний код, бывают очень разные, в каждой из них свои причины. Сторонний код может быть закрытым (например, с помощью энкодера), наложение патча на чужой код при каждом обновлении может оказаться намного дороже, чем monkey patching, «починка» может противоречить видению авторов библиотеки или нуждам остальных ее пользователей и т.д. и т.п.

Теперь все релизы официально на pecl.php.net/runkit! Текст статьи обновлен.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории