Pull to refresh

Comments 26

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

Я сделал приблизительные оценки этой задачи по времени и по стоимости – числа получаются большие, т.е. либо желающих получить Runkit для PHP7 должно быть много, либо среди них должны быть щедрые желающие, возможно, компании.
UFO just landed and posted this here
Предполагаю, что для модульного тестирования и песочниц. И еще для обновления кода на лету. Кроме того, программы на 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, «починка» может противоречить видению авторов библиотеки или нуждам остальных ее пользователей и т.д. и т.п.

Sign up to leave a comment.

Articles