Ситуации, когда нельзя или нет смысла править сторонний код, бывают очень разные, в каждой из них свои причины. Сторонний код может быть закрытым (например, с помощью энкодера), наложение патча на чужой код при каждом обновлении может оказаться намного дороже, чем monkey patching, «починка» может противоречить видению авторов библиотеки или нуждам остальных ее пользователей и т.д. и т.п.
Полгода назад релиза 1.0.4 еще не было и PHP 5.5 и 5.6 не поддерживались. Надеюсь, сейчас у вас никаких сегфолтов Runkit не вызывает. Если что-то не работает — ставьте issue на github'е, починю.
Тут, как говорится, на вкус на цвет. Можно по-настоящему заменять методы и функции в рантайме на заглушки, а можно вместо каждого include() сначала делать file_get_contents(), потом preg_replace(), оборачивающий всевозможные места в коде (вызовы функций, тела методов и т.п.) в if'ы с заглушками, а потом получившийся код eval()'ить, как это примерно и происходит в Go-AOP, на основе которого работает AspectMock.
В 2006-м я использовал и оба подхода параллельно, сейчас мне больше нравится Runkit.
Да, AspectMock может, если у вас PHP 5.4+ и вы никогда не делаете заглушки для функций.
На мой взгляд, заглушки для функций (в том числе для функций, встроенных в PHP) в тестах бывают очень полезны.
Предполагаю, что для модульного тестирования и песочниц. И еще для обновления кода на лету. Кроме того, программы на PHP5 очень легко переедут на PHP7.
Плохой код, к сожалению, не редкость. С другой стороны, проектирование архитектуры кода с точки зрения тестируемости может идти вразрез с проектированием с точки зрения эффективности и быстроты реализации.
Если не заменять заглушками тестируемые функции, то ошибки никуда не скроются, все будет хорошо. А как без такого инструмента тестировать поведение методов, не поддерживающих dependency injection?
Владислав, спасибо за вопрос. Дело вот в чем, чтобы Runkit завелся под PHP7, нужно проделать большую работу, на длительное время сделать это основной своей деятельностью. Но надо же при этом что-то есть. Так что вся надежда на пожертвования пользователей: если это будут нормальные достойные суммы и, главное, если таких пожертвований будет много, то Runkit под PHP7 быстро станет реальностью.
Я сделал приблизительные оценки этой задачи по времени и по стоимости – числа получаются большие, т.е. либо желающих получить Runkit для PHP7 должно быть много, либо среди них должны быть щедрые желающие, возможно, компании.
На мой взгляд, эта фраза чисто негативная:
1) человек пишет, что при поиске был ограничен по времени;
2) человек не смог ничего найти;
3) человек замечает, что мог что-то упустить;
4) человек приносит извинения.
Спасибо за интересный вопрос.
Мы работаем так, что у нас все получается. Если что-то не удается, то только потому, что задача еще не завершена и скоро все удастся.
В статье я постарался рассказать вещах, от которых мы отказались. Главным образом, это скучные однообразные задачи и регулярные действия, которые можно передать роботам.
По поводу приемов тестирования, которые не работают сказать что-либо сложно, т.к. мы ищем те, что работают. Неработающих приемов много, но они быстро забываются. Хотя один пример все-таки есть: http://www.youtube.com/watch?v=VQAmMwPx1Vc
Спасибо за вопрос. Алексею, как сотруднику нашей компании, я ответил более подробно в личной переписке. Здесь же в рамках той информации, которую я могу раскрывать, могу сказать только то, что сейчас компания Mail.Ru Group тестирует все свои проекты и продукты.
Тут, как говорится, на вкус на цвет. Можно по-настоящему заменять методы и функции в рантайме на заглушки, а можно вместо каждого include() сначала делать file_get_contents(), потом preg_replace(), оборачивающий всевозможные места в коде (вызовы функций, тела методов и т.п.) в if'ы с заглушками, а потом получившийся код eval()'ить, как это примерно и происходит в Go-AOP, на основе которого работает AspectMock.
В 2006-м я использовал и оба подхода параллельно, сейчас мне больше нравится Runkit.
На мой взгляд, заглушки для функций (в том числе для функций, встроенных в PHP) в тестах бывают очень полезны.
Я сделал приблизительные оценки этой задачи по времени и по стоимости – числа получаются большие, т.е. либо желающих получить Runkit для PHP7 должно быть много, либо среди них должны быть щедрые желающие, возможно, компании.
1) человек пишет, что при поиске был ограничен по времени;
2) человек не смог ничего найти;
3) человек замечает, что мог что-то упустить;
4) человек приносит извинения.
Мы работаем так, что у нас все получается. Если что-то не удается, то только потому, что задача еще не завершена и скоро все удастся.
В статье я постарался рассказать вещах, от которых мы отказались. Главным образом, это скучные однообразные задачи и регулярные действия, которые можно передать роботам.
По поводу приемов тестирования, которые не работают сказать что-либо сложно, т.к. мы ищем те, что работают. Неработающих приемов много, но они быстро забываются. Хотя один пример все-таки есть: http://www.youtube.com/watch?v=VQAmMwPx1Vc