используя такой подход, вы завязываете реализацию своих тестов на внутренней структуре объектов, а не на интерфейсе объектов, иначе говоря, тесты будут ломаться, когда код будет фактически работоспособным.
Упавшие тесты не составит особого труда пофиксить, а что вам даст уверенность что после изменения внутренней структуры класса, вы не поломали его логику?
Я для того и упомянул об особенностях юнит тестирования в обзоре, — обратите внимание на пункт Для чего нужно юнит тестирование.
При адекватном использовании моков, такие неоправданные падения тестов будут скорее исключением чем правилом.
Во вторых, упавшие тесты заставляют держать руку на пульсе — человек который их фиксит, волей-неволей должен вникнуть в логику работы класса который он изменил(а юнит тесты как раз и документируют логику классов). Это особенно важно в коллективной разработке, когда над одним проектом трудятся десяток и более девелоперов.
Наиболее эффективными (но и трудоемкими в написании) являются тесты, основанные на использовании тестовых реализаций
Вам не кажется что это те же самые моки, только реализованные вручную? Какие преимущества с точки зрения юнит-тестирования дает такой подход(кроме увеличения скорости работы тестов и простоты набивки тестовых данных)?
Мой сотрудник подписался на один из подобных cервисов, не вводя никуда никаких кодов — просто нажав случайно OK на одном из входящих рекламных Flash сообщений. Сразу сняли 8 грн, хорошо что он вовремя заметил и отписался от сервиса позвонив оператору. Вот собственно список этих замечательных сервисов.
При желании абонент может отказаться от услуги получения информационных (рекламных) SMS-сообщений. Для отказа необходимо отправить SMS сообщение на номер 10250.
В природе существует предостаточное количество Isolation Frameworks с более-менее похожими возможностями, при этом каждый фреймворк имеет свои особенности. К примеру я не нашел в Moq возможности редиректить вызовы статических и приватных членов классов — а вот Moles умеет это делать.
В конце концов, каждый волен выбирать то, что ему подходит больше.
Упавшие тесты не составит особого труда пофиксить, а что вам даст уверенность что после изменения внутренней структуры класса, вы не поломали его логику?
Я для того и упомянул об особенностях юнит тестирования в обзоре, — обратите внимание на пункт Для чего нужно юнит тестирование.
При адекватном использовании моков, такие неоправданные падения тестов будут скорее исключением чем правилом.
Во вторых, упавшие тесты заставляют держать руку на пульсе — человек который их фиксит, волей-неволей должен вникнуть в логику работы класса который он изменил(а юнит тесты как раз и документируют логику классов). Это особенно важно в коллективной разработке, когда над одним проектом трудятся десяток и более девелоперов.
Вам не кажется что это те же самые моки, только реализованные вручную? Какие преимущества с точки зрения юнит-тестирования дает такой подход(кроме увеличения скорости работы тестов и простоты набивки тестовых данных)?
В конце концов, каждый волен выбирать то, что ему подходит больше.