Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
А как продвигается работа в направлении поддержки PHP7? Релиз уже близко :)
Владислав, спасибо за вопрос. Дело вот в чем, чтобы Runkit завелся под PHP7, нужно проделать большую работу, на длительное время сделать это основной своей деятельностью. Но надо же при этом что-то есть. Так что вся надежда на пожертвования пользователей: если это будут нормальные достойные суммы и, главное, если таких пожертвований будет много, то Runkit под PHP7 быстро станет реальностью.
Я сделал приблизительные оценки этой задачи по времени и по стоимости – числа получаются большие, т.е. либо желающих получить Runkit для PHP7 должно быть много, либо среди них должны быть щедрые желающие, возможно, компании.
Я сделал приблизительные оценки этой задачи по времени и по стоимости – числа получаются большие, т.е. либо желающих получить Runkit для PHP7 должно быть много, либо среди них должны быть щедрые желающие, возможно, компании.
Предполагаю, что для модульного тестирования и песочниц. И еще для обновления кода на лету. Кроме того, программы на PHP5 очень легко переедут на PHP7.
Он нужен, чтобы заткнуть архитектурные проблемы старого и/или неподдерживаемого кода.
Я бы не был столь категоричен. RunKit используется по-разному. И аналога многим его возможностям в PHP7 нет.
Ух ты, он живой :)
Отличная работа, спасибо.
Отличная работа, спасибо.
Боже мой, этим даже пользуются и ждут релиза? Я бы за использование этого казнил бы на месте! Это же как людям не хватало кривых рук, что они придумали костыли в рантайме делать?
В продакшен-системе его использовать и правда не стоит, а вот для юнит-тестов и создания моков без необходимости использовать DI это расширение очень даже ничего.
Вы ж учтите что используя это в юнит тестах, можно что-то «изменить» так, что тесты будут проходить, а вот собственно ошибки останутся. Поэтому теоретически да, можно использовать в юнит тестировании, но на практике я бы и там не решился бы это использовать. Просто сделать метод видимым и протестировать его можно и без этой библиотеки.
Если не заменять заглушками тестируемые функции, то ошибки никуда не скроются, все будет хорошо. А как без такого инструмента тестировать поведение методов, не поддерживающих dependency injection?
Есть куда более простые альтернативы для тестирования такого кода без сторонних расширений PHP.
Например AspeckMock.
Например AspeckMock.
Да, AspectMock может, если у вас PHP 5.4+ и вы никогда не делаете заглушки для функций.
На мой взгляд, заглушки для функций (в том числе для функций, встроенных в PHP) в тестах бывают очень полезны.
На мой взгляд, заглушки для функций (в том числе для функций, встроенных в PHP) в тестах бывают очень полезны.
Что значит заглушки для функций? AspectMock как раз и позволяет мокать любые функции.
В том числе стандартные функции PHP пруф
В том числе стандартные функции PHP пруф
Простите, недооценил AspectMock.
Тут, как говорится, на вкус на цвет. Можно по-настоящему заменять методы и функции в рантайме на заглушки, а можно вместо каждого include() сначала делать file_get_contents(), потом preg_replace(), оборачивающий всевозможные места в коде (вызовы функций, тела методов и т.п.) в if'ы с заглушками, а потом получившийся код eval()'ить, как это примерно и происходит в Go-AOP, на основе которого работает AspectMock.
В 2006-м я использовал и оба подхода параллельно, сейчас мне больше нравится Runkit.
Тут, как говорится, на вкус на цвет. Можно по-настоящему заменять методы и функции в рантайме на заглушки, а можно вместо каждого include() сначала делать file_get_contents(), потом preg_replace(), оборачивающий всевозможные места в коде (вызовы функций, тела методов и т.п.) в if'ы с заглушками, а потом получившийся код eval()'ить, как это примерно и происходит в Go-AOP, на основе которого работает AspectMock.
В 2006-м я использовал и оба подхода параллельно, сейчас мне больше нравится Runkit.
В целом вы правы это на вкус и цвет.
Но у runkit есть существенный минус в том что это отдельное расширение для PHP и его нужно ставить отдельно.
И всего пол года назад я его поставить и вовсе не смог, а точнее не смог использовать, по причине сегфолтов. У AspectMock такого минуса нет.
К слову не «как это происходит в Go-AOP», а собственно AspeckMock на Go-AOP и построен =)
Но у runkit есть существенный минус в том что это отдельное расширение для PHP и его нужно ставить отдельно.
И всего пол года назад я его поставить и вовсе не смог, а точнее не смог использовать, по причине сегфолтов. У AspectMock такого минуса нет.
К слову не «как это происходит в Go-AOP», а собственно AspeckMock на Go-AOP и построен =)
А кстати, почему бы не использовать в продакшене? Я знаю один высоконагруженный проект, в котором это делали еще в 2006-2007-м.
Если глючит сторонний код (библиотеки, каркаса или расширения), то почему бы и не «починить», то есть подменить его таким макаром? Всё лучше чем ждать у моря погоды.
Ситуации, когда нельзя или нет смысла править сторонний код, бывают очень разные, в каждой из них свои причины. Сторонний код может быть закрытым (например, с помощью энкодера), наложение патча на чужой код при каждом обновлении может оказаться намного дороже, чем monkey patching, «починка» может противоречить видению авторов библиотеки или нуждам остальных ее пользователей и т.д. и т.п.
Теперь все релизы официально на pecl.php.net/runkit! Текст статьи обновлен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новое в Runkit 1.0.4: PHP 5.6+, closures везде и еще 12 новых фич