Вы, видимо, не читали статьи. Сеттеры можно оставить в реализации, а работать по интерфейсу, в котором сеттера не будет, зависимости можно внедрить через конструктор. Если ваши объекты инстанцируются через фабрику или IOC-контейнер до конструктора вы тоже не дотянитесь.
Черный ход здесь не при чем. Качество кода ради тестируемости на падает, а улучшается, т.к. тестируемый код подразуевает слабую связь компонентов.
Страустрап в своей книге о C++ предлагает следующий подход к ООП в целом: если «это» действие — сделайте метод. Если несколько действий объединены общим смыслом и/или процессом — объявите класс. Если придерживаться этого правила, то автоматом класс будет модулем вашего приложения.
Внешняя зависимость — это все, что делает ваши тесты не правдивыми и сложно-поддерживаем. Файловая система — зависимость: структура каталогов может быть другой на другой машине. БД — зависимость, ее может не быть на другой машине. Веб-сервис — зависимость: может не быть интернета или может быть злобный фаервол, а сервис, вообще может взять и упасть, скажем, от Хабра-эффекта.
Спросите себя: «будет ли этот компонент вести себя так же на другой машине?». Если ответ «нет»: нужно его подменить. Если ответ «да» — оставьте его.
Некоторые разработчики начинают увлекаться подменой сущностей и приходят к тому, что подменяют вообще все. Они перестают тестировать приложение и начинают тестировать свои стабы, моки. Это в корне не верно. Если «живых» реализаций в тесте нет, то этот тест не тестирует ничего.
Существует перегиб в обратную сторону. В readme NHibernate'а, не знаю, как сейчас, в прошлых релизах был пункт «пожалуйста, не тестируйте NHibernate, у нас есть свои тесты. Тестируйте вашу бизнес-логику».
Калькулятор — де факто, — уже промышленный стандарт примеров тестирования. Я в этих местах писал о форме записи и способах декомпозиции. Пример умышленно упрощен, чтобы акцентировать не тестируемом методе, а на способах решения выше обозначенных проблем.
нет, вам нужно отдельно тестировать слои приложения, отвечающие за Data Layer, а в другие классы передать фейки ваших Data Layer — объектов. Правило простое: один класс — один тестирующий класс. Если вы будете сразу тестировать с БД — это несколько слоев приложение. Это интеграционный, а не юнит-тест.
Вообще, статья как раз о том, что и как тестировать. Вы точно дочитали до конца? Исходя из вашего коммента (не очень много информации) я предложил бы вам точно протестировать добавление и отображение «расходов» ;)
Я бы добавил, что можно уделять время, для того, чтобы нас окружали мудрые и компетентные люди. Все-таки особо-отмороженные в IT меньше, чем не опытных. Если вы что-то понимаете лучше — образовывайте других людей. Это сложно, но возможно.
Тогда не удивляйтесь, что менеджеры, в свою очередь, будут тоже «использовать инкапсуляцию на всю катушку» и класть на ваши рефакторинги, архитектуру и прочие «излишества. Должен быть здоровый компромисс. Оптимально, чтобы у менеджера был, хотя бы минимальный технический бекграунд. Программист, в свою очередь, должен „снисходить до простых смертных“ и общаться с другими участниками команды на их языке. Это не сложно, просто вопрос привычки.
— Вася, сколько времени это займет?
— Семен, смотри, у нас 2 пути. Можно наговнокодить за день чего-то. Кушать это ложкой будем потом еще 2 недели: это называется технический долг (мы берем время как-бы „взаймы“ — отдавать придется с процентами). Второй вариант. Есть одна штука в этой задаче, с которой я еще не работал, давай заведем задачу на ресерч на 4 часа, а потом я смогу дать более точную оценку. Думаю, что за 4-5 дней можно сделать все с шиком, блеском.
Если менеджер не конченный псих, то время на ресерч вам дадут.
Очень частая ошибка при переводе индийских слов: «Маратхи» вместо «Марати», «Гатх» вместо «Гат». Т.к. Индия была долгое время английской колонией, многие слова там написаны на английском, через gh или th. Все переводят не с оригинала, а с английских транскрипций… коряво.
Дарт Оптимизатурус. Разворачивает все циклы, которые видит, не приенят foreach в принципе, использует указатели и работает с памятью напрямую, не смотря на то, что пишет на C#. Не признает слоев приложения, потому что это «замедляет программу».
Дарт ИнлайнСтайл — не признает css в отдельном файле и пишет все стили прямо в теги. Обычно предпочитает «старые добрые таблицы» и атрибуты border, width, height, etc.
Хотя для открытия счета и потребуется паспорт, да. Другой вопрос, что я очень сильно сомневаюсь, что европейские или американские банки вот так возьмут и начнут раскрывать информацию российской налоговой. В общем, суть в том, что это закон, исполнение которого, довольно сложно проконтролировать. Направлен он просто на грабеж граждан. В Европе вы в аналогичном случае просто выбираете страну, в которой вы платите налоги.
Я просто указал на то, как обходить этот закон в конкретном случае: человек живет и работает в другой стране и есть опасения по поводу того, что теперь он должен проводить деньги через российские банки. То, что закон направлен на залезание в карман к гражданам даже не обсуждается.
Черный ход здесь не при чем. Качество кода ради тестируемости на падает, а улучшается, т.к. тестируемый код подразуевает слабую связь компонентов.
Внешняя зависимость — это все, что делает ваши тесты не правдивыми и сложно-поддерживаем. Файловая система — зависимость: структура каталогов может быть другой на другой машине. БД — зависимость, ее может не быть на другой машине. Веб-сервис — зависимость: может не быть интернета или может быть злобный фаервол, а сервис, вообще может взять и упасть, скажем, от Хабра-эффекта.
Спросите себя: «будет ли этот компонент вести себя так же на другой машине?». Если ответ «нет»: нужно его подменить. Если ответ «да» — оставьте его.
Некоторые разработчики начинают увлекаться подменой сущностей и приходят к тому, что подменяют вообще все. Они перестают тестировать приложение и начинают тестировать свои стабы, моки. Это в корне не верно. Если «живых» реализаций в тесте нет, то этот тест не тестирует ничего.
Существует перегиб в обратную сторону. В readme NHibernate'а, не знаю, как сейчас, в прошлых релизах был пункт «пожалуйста, не тестируйте NHibernate, у нас есть свои тесты. Тестируйте вашу бизнес-логику».
— Вася, сколько времени это займет?
— Семен, смотри, у нас 2 пути. Можно наговнокодить за день чего-то. Кушать это ложкой будем потом еще 2 недели: это называется технический долг (мы берем время как-бы „взаймы“ — отдавать придется с процентами). Второй вариант. Есть одна штука в этой задаче, с которой я еще не работал, давай заведем задачу на ресерч на 4 часа, а потом я смогу дать более точную оценку. Думаю, что за 4-5 дней можно сделать все с шиком, блеском.
Если менеджер не конченный псих, то время на ресерч вам дадут.