Конечно не значит что надо писать синглтоны повсюду. Но ограниченное их число для каких-то глобальных обьектов вполне допустимо.
Например, конфигурацию, вполне неплохо держать в синглтоне.
Если мокнуть Number::instance() я никаким образом не буду тестировать глобальное состояние. Наоборот. Я его отключаю.
Мы как раз убираем все внешние зависимости (какими бы они не были) и делаем полноценный юнит тест.
Если бы Number::instance оставался включенным, это был бы интеграционный тест…
То есть, при проходе теста мы ни на строчку не выходим за пределы тестируемого класса, мы не обращаемся к другим классам системы.
Что собственно и является юнит тестированием.
Хм, а может кто расскажет, что в елементари взято не из MacOS?
Судя по скриншотам и общей концепции кажется, будто это убунта с маковым интерфейсом.
Поправьте меня :)
… при этом тролили меня на реддите с AspectMock :)
Ваш код будет работать ровно до того момента пока мы явно не укажем класс для требуемых зависимостей:
public function __construct($name, Tree $home_tree)
Ничего нет сложного, чтобы создать из массива обьект, а вот заставить этот обьект полностью вести себя как экземпляр некого класса, это уже задача гораздо сложнее.
Но, посмотрев зависимости, я понял, что мне столько всего не нужно.
Тут вынужден согласиться. Зависимостей уже более чем дофига и возможно пора уже выносить что-то в отдельные пакеты.
Но реальность такова, что самой главной зависимости — PHPUnit, пока нет альтернатив. На чуть более менее сложном проекте он должен быть. Не зря его называют «стандартом де факто» в тестировании. Возможно он черезмерно тяжел и раздут, но более менее серьезный проект разрабатывать без него не стоит.
Грустно. Как без нативного клиента этим пользоваться. Что делать, если единственная социальная функция вконтакта — общение, удаляется?
Мне не нужны новости, стенки, тупые цитаты, картинки с котиками, даже пиратские записи и порно. Мне нужно простые механизмы общения. Желательно унифицированый механизм через тот же Pidgin. Спасибо Дурову :( Котики видать ценнее.
Да, я понимаю про обратную сторону. И не имею цели переубеждать адептов TDD. Просто хотел бы обладать возможностями Ruby/JavaScript для тестирования. Как ни крути, а в этих сообществах к тестированию относятся более серьезно. Пусть порой и забивают как на законы Деметры, так и на использование DI. Главное, чтобы код тестировался, а кто уже и как, чуть менее важно.
В то же время, DI позволяет явно контролировать, что от чего зависит (в том числе в тестах), так что вышеописанной ситуации там произойти не должно. К тому же, если вы пишете в стиле TDD, то у вас автоматом получается хорошая архитектура, и вам не надо ломать голову, как же покрыть код тестами.
Доктор, я не могу работать по TDD хотя бы потому, что мне нужно сначала вписать код, проверить синтаксис, посмотреть как этот код будет вписываться в остальную архитектуру, перебрать кучу вариантов внедрения и выбрать оптимальный. TDD мне не позволяет перебирать всё эти варианты, только затормаживает необходимостью, включать туда зависимости.
Я лучше попробую разные варианты, посмотрю на возможные косяки в реализации, и найду из них самый простой, короткий и оптимальный.
Тогда покрою его тестом.
Ну у этой медали есть оборотная сторона: вам при написании теста надо обязательно знать скрытые детали устройства того, что вы тестируете. Например, замОчили вы User::save, а потом кто-то поменял класс и добавил туда еще какой-нибудь UserSettings::save. И все, вы в тесте пропустили этот вызов.
Не так всё ужасно. В любом нормальном ORM есть один метод для записи в БД. Это один из родительских классов всех моделей. Если замОчить его, то вызов мы никак не пропустим.
детская порнография вроде как должна идти через МВД.
А какие финансы там собирать?
ВКонтакт что ли налоги не заплатил в бюджет выкладывая детское порно?
На самом деле, во многих динамических языках это хорошая практика. Доступиться до приватного свойства сложно, но можно.
И это хорошо, я считаю. Мы не настолько криворукие как могут считать разработчики либ, зачем нас искусственно ограничивать?
Вы определитесь, вам юнит тесты или интеграционные нужны :)
Если вы говорите про «реальную прогу» это уже никак не тест отдельного компонента.
Например, конфигурацию, вполне неплохо держать в синглтоне.
Если мокнуть Number::instance() я никаким образом не буду тестировать глобальное состояние. Наоборот. Я его отключаю.
Мы как раз убираем все внешние зависимости (какими бы они не были) и делаем полноценный юнит тест.
Если бы Number::instance оставался включенным, это был бы интеграционный тест…
То есть, при проходе теста мы ни на строчку не выходим за пределы тестируемого класса, мы не обращаемся к другим классам системы.
Что собственно и является юнит тестированием.
Судя по скриншотам и общей концепции кажется, будто это убунта с маковым интерфейсом.
Поправьте меня :)
Ваш код будет работать ровно до того момента пока мы явно не укажем класс для требуемых зависимостей:
Ничего нет сложного, чтобы создать из массива обьект, а вот заставить этот обьект полностью вести себя как экземпляр некого класса, это уже задача гораздо сложнее.
Тут вынужден согласиться. Зависимостей уже более чем дофига и возможно пора уже выносить что-то в отдельные пакеты.
Но реальность такова, что самой главной зависимости — PHPUnit, пока нет альтернатив. На чуть более менее сложном проекте он должен быть. Не зря его называют «стандартом де факто» в тестировании. Возможно он черезмерно тяжел и раздут, но более менее серьезный проект разрабатывать без него не стоит.
Мне не нужны новости, стенки, тупые цитаты, картинки с котиками, даже пиратские записи и порно. Мне нужно простые механизмы общения. Желательно унифицированый механизм через тот же Pidgin. Спасибо Дурову :( Котики видать ценнее.
Доктор, я не могу работать по TDD хотя бы потому, что мне нужно сначала вписать код, проверить синтаксис, посмотреть как этот код будет вписываться в остальную архитектуру, перебрать кучу вариантов внедрения и выбрать оптимальный. TDD мне не позволяет перебирать всё эти варианты, только затормаживает необходимостью, включать туда зависимости.
Я лучше попробую разные варианты, посмотрю на возможные косяки в реализации, и найду из них самый простой, короткий и оптимальный.
Тогда покрою его тестом.
Не так всё ужасно. В любом нормальном ORM есть один метод для записи в БД. Это один из родительских классов всех моделей. Если замОчить его, то вызов мы никак не пропустим.
Но свобода информации дороже :)
А какие финансы там собирать?
ВКонтакт что ли налоги не заплатил в бюджет выкладывая детское порно?
А вдруг IQ наших школьников чуть повысится.
И это хорошо, я считаю. Мы не настолько криворукие как могут считать разработчики либ, зачем нас искусственно ограничивать?
Вроде ж остался только один, нет?