PHP Статические методы/шаблон Singleton

Question

Я разрабатываю новую архитектуру программного продукта моей компании. Я довольно новичок в модульном тестировании. Я прочитал некоторые ужасные истории об использовании одноэлементных и статических методов, но я не совсем понимаю проблему с их использованием и буду благодарен за некоторое просветление.

Вот что я делаю:

У меня есть архитектура многоуровневой. На уровне сервера я использую ряд повторно используемых объектов для представления таблиц базы данных, называемых «Обработчики». Эти обработчики используют другие объекты, такие как XMLObjects, XMLTables, различные Datastructures и т. Д. Большинство из них являются домашними, а не ваши предварительно упакованные объекты. Во всяком случае, поверх этого слоя находится псевдоожиженный слой. Основной целью этого является упрощение более высоких уровней кода на стороне сервера и создание бесшовного управления классами. Могу сказать:

$tablehandler = databasename::Handler('tablename') 

... чтобы получить стол. Я не вижу врожденной проблемы с этим. Я использую стек обработчиков (ассоциативный массив), чтобы содержать экземпляры разных объектов. Я не использую глобальные переменные, и все статические данные являются защищенными или частными. Мой вопрос заключается в том, как это может вызвать проблемы с модульным тестированием. Я не ищу риторики победителей, я ищу причинную связь. Я также был бы признателен за любое другое понимание этого. На данный момент я чувствую себя чрезвычайно гибкой и эффективной архитектурой. Любая помощь здесь была бы замечательной.

Answer 1

Использование статических методов для обеспечения доступа к управляемым экземплярам - будь то одиночные, объединенные объекты или экземпляры «на лету» - не является проблемой для тестирования, если вы предоставляете способ тестирования при необходимости приложите свои собственные макеты и заглушки и удалите их после завершения. Из вашего описания я не вижу ничего, что могло бы блокировать эту способность. Вам просто нужно построить его, когда это необходимо.

Вы столкнетесь с трудностями, если у вас есть класс, который статически вызывает методы, которые выполняют работу без точки расширения или проходят через экземпляр. Например, вызов, как этот

UserTable::findByEmail($email); 

делает тестирование трудно, потому что вы не можете подключить поругание памяти только таблицы и т.д. Тем не менее, изменение его

UserTable::get()->findByEmail($email); 

решает эту проблему, потому что тест может вызвать UserTable::set($mock) в установочном коде. Более подробный пример см. В разделе this answer.