Вы ввели новый интерфейс — вы должны сейчас написать к нему тест. Вне зависимости от того, насколько проста его реализация.
У вас есть студенты, которые сейчас хранятся в studentList. И есть множество подсистем, которые написаны разными людьми и используют этот studentList.
Потом васяпупкен внёс коррективы в схему хранения, запустил тесты и увидел где что упало.
А то что теперь не работает hasAnyStudents() не увидел, так как вы к ней тест не написали, а он о её существовании может ничего и не знать.
bool SuperPuperClass::hasAnyStudents() { return !this.studentsList.empty(); }
Что мы в этом примере должны проверять? Что метод std::list::empty() работает как надо?
Нет, здесь должны проверять, что hasAnyStudents() работает корректно.
Предлагаю наиболее простое и дешёвое решение.
Интернет-камера передаёт картинку на определённый ресурс, там сидит индус и определяет, есть ли человек или нет. И жмёт определённую кнопку каждые 5 секунд.
Не в конструкции дело. Конструкции можно любые сделать, да и PHP итак не самый красивый язык в плане конструкций.
Я о самом принципе.
Есть класс, экземпляры которого могут иметь настраиваемое поведение (реализации вложенных подсистем лишь один из видов настройки).
Отдельно пишем класс по возможности обобщённо, отдельно конфиги к нему. А объект сам по своему конфигу себя инициализирует, как хочет.
Не надо вызывать потом отдельно методы, подсовывать ему незаметно какие-то объекты в поля. Сразу после конструктора у нас завершённый, неизменяемый, готовый к работе объект.
А уже GoogleFinder в своём конструкторе смотрит в конфиг и для $this->finder создаёт экземпляр класса MyMock. А для тех, что не определены, использует классы по умолчанию ($this->grabber = new Grabber()).
А лучше была бы возможность просто один раз передать список.
Вы сразу в табло бьёте, как только человек заикнулся про 7 единиц?
Вот сравнение, например: blgo.ru/blog/2013/08/07/autoload-req-pha/
Вы ввели новый интерфейс — вы должны сейчас написать к нему тест. Вне зависимости от того, насколько проста его реализация.
У вас есть студенты, которые сейчас хранятся в studentList. И есть множество подсистем, которые написаны разными людьми и используют этот studentList.
Потом васяпупкен внёс коррективы в схему хранения, запустил тесты и увидел где что упало.
А то что теперь не работает hasAnyStudents() не увидел, так как вы к ней тест не написали, а он о её существовании может ничего и не знать.
Нет, здесь должны проверять, что hasAnyStudents() работает корректно.
Интернет-камера передаёт картинку на определённый ресурс, там сидит индус и определяет, есть ли человек или нет. И жмёт определённую кнопку каждые 5 секунд.
зачем городить глобальные HttpRequest, HttpRequestException, HttpURLConnection? Не говоря уже про SocketInterface.
Я о самом принципе.
Есть класс, экземпляры которого могут иметь настраиваемое поведение (реализации вложенных подсистем лишь один из видов настройки).
Отдельно пишем класс по возможности обобщённо, отдельно конфиги к нему. А объект сам по своему конфигу себя инициализирует, как хочет.
Не надо вызывать потом отдельно методы, подсовывать ему незаметно какие-то объекты в поля. Сразу после конструктора у нас завершённый, неизменяемый, готовый к работе объект.
А уже GoogleFinder в своём конструкторе смотрит в конфиг и для $this->finder создаёт экземпляр класса MyMock. А для тех, что не определены, использует классы по умолчанию ($this->grabber = new Grabber()).