Есть функция f(), не принимающая параметров и содержащая другие функции f1, f2, f3, f4, expect. Другие функции (f1, f2, f3, f4, expect) описаны в подключаемом файле. Функция f2 - записывает данные в БД. Функция expect - считывает данные из БД. Стоит задача проверить, что данные, предназначенные для записи в БД ($p), равны данным, которые считаются из БД.
require_once (<файл с подключаемыми функциями>);
function f() {
global $v;
$v->method();
$p = $v->method2();
$p['key1'] = f1();
$p['key2'] = strlen($p['key2']);
f2 ($p);
f3();
f4();
}
Есть файл с кодом теста PHPunit
/**
* @dataProvider pProvider
*/
public function test_f($p) {
// что-то надо добавить
f();
$exp = expect();
$this->assertEquals($p, $exp);
}
public function pProvider()
{
return array (
array('string1'),
array('string12'),
array('string123'),
array('string1234')
);
}
Вопросы:
Первое, что нужно сделать - избавиться от global. Тут и везде по своему проекту. Никогда, нигде ни при каких обстоятельствах не используйте global. Это явный признак плохой архитектуры. Так называемый "запах" кода.
Для выполнения первого пункта почитайте про DI. Это как раз про вынесение $v наружу и передачи её внутрь функции в качестве аргумента. Таким же аргументом будет и ваша $p.
После этого у вас уже не будет проблем с передачей контекста внутрь тестируемой функции.
Функции внутри тестируемой лучше мокать, а не использовать оригинальные версии. Т.к. сейчас получается, что вы тестируете базу данных, а не саму функцию. Если тест именно юнит, а не компонентный/функциональный/UI, то нет смысла тестировать всё совокупно. Напишите тесты отдельно для каждой функции, для каждой атомарной неделимой части вашего кода. А обвязку над всеми функциями отложите на потом, - это тест другого уровня.
Апостиль в Лос-Анджелесе без лишних нервов и бумажной волокиты
Основные этапы разработки сайта для стоматологической клиники
Продвижение своими сайтами как стратегия роста и независимости