Скажем, я использую такой фреймворк, как Slim (PHP), и у меня есть довольно современная структура кода:
$app->post("/", function($request, $response) {
// define the post actions here
});
Я мог бы поместить анонимную функцию в отдельный класс, но есть ли способ написать тест без потери этой структуры кода?
Спасибо.
@nima "модульный тест для этой анонимной функции"






есть несколько способов проверить это. Тем не менее, я бы рекомендовал разделить каждый обработчик на отдельный файл (возможно, даже на класс, у которого есть метод __invoke). Причина в том, что теперь такой способ определения обработчиков выглядит коротким и четким. Но как только у вас будет более 10 конечных точек, это станет действительно некрасивым в обслуживании, и вы смешиваете логику маршрутизации вместе с разными обработчиками.
Если это очень маленький проект, и вы хотите сохранить такой синтаксис, есть две стратегии для его тестирования. Но имейте в виду, что оба они будут немного более громоздкими, чем вам хотелось бы:
Стиль интеграционного теста (НЕ рекомендуется)
вы просто вызываете $slim->run() в своих тестах и проверяете, соответствует ли вывод обработчика вашим ожиданиям. Slim предлагает хороший способ имитировать HTTP-запрос как вы можете найти внизу этой страницы. Имейте в виду, что вы будете ограничены проверкой только тех данных, которые возвращаются вашим обработчиком. Если ваш обработчик возвращает простой HTML, вы можете только проверить, что возвращенный html содержит правильные вещи.
Вы могли бы пойти немного дальше, если бы использовали функцию инъекции зависимостей slim и предоставили ей макеты.
Простой стиль обработчика (рекомендуется)
В качестве альтернативы вы также можете сохранить свою анонимную функцию обработчика в маршрутизации, но отложить обработку фактической бизнес-логики до другого класса, который затем можно было бы протестировать. Если ваш контроллер очень простой и ничего не делает, кроме получения параметров GET / POST и пересылки их классу, то для него не так много тестирования.
Помимо того, что это дает вам возможность проверить, это также лучший способ подумать о разделении проблем. Ваша функция тонкого обработчика позаботится о структуре и основах HTTP, и у вас будет хороший предметный класс, которому не нужно беспокоиться об этом.
$app->post("/register", function() {
$result = (new RegisterUserAction())
->register($_POST["email"], $_POST["password1"], $_POST["password2"]);
// now use $result to render the html page to show to the user
});
Если вы хотите протестировать именно эту анонимную функцию, вы можете попробовать имитировать переменную $app:
$app = $this->getMockBuilder('app class')->disableOriginalConstructor()
->setMethods(['post'])
->getMock();
$app->method('post')->willReturnCallback(function ($url, $anonymousFunction) {
// do some tests with $anonymousFunction
});
Ваш вопрос о написании модульного теста для этой анонимной функции? Или вы спрашиваете о чем-то вроде интеграционного теста?