State verification – проверяется состояние системы после вызова , сравнивается с ожидаемым.
Каким образом протестировать класс Sale?
Behavior. Каждый тест описывает не только взаимодействие клиентов с тестируемой системой , но и взаимодействие тестируемой системы с компонентами , от которых она зависит. Это позволяет убедиться , что система ведет себя ожидаемым образом. Практически всегда подразумевает замену вызываемого компонента. Может использоваться всякий раз , когда тестируемая система вызывает методы других объектов или компонентов. Хрупкость тестов(много сведений о реализации SUT ). Повышение стоимости обслуживания тестов. Используйте по назначению.
Вызываемые компоненты могут возвращать значения или генерировать исключения , влияющие на поведение тестируемой системы , но некоторые из таких случаев практически невозможно спровоцировать , либо дорого. Пример – системные часы , недоступность сети , календарь Многие ветви выполнения предназначены для работы с возвращаемыми значениями и обработки возможных исключений. Появляется запах Untested Code. Эффективное тестирование этих ветвей кода – сложная задача , но именно они с большей вероятностью и приводят к катастрофическим отказам. Реальный компонент можно заставить сгенерировать необходимый ввод , но это потребует слишком больших накладных расходов. Test Double – любой объект ил компонент , который устанавливается вместо реального компонента на время работы теста. Вставка зависимости. Либо Dependency Injection либо Dependency Lookup( в legacy системах более удобно ). Классы Singleton приводят к проблемам при написании тестов Создание подкласса SUT – последний шанс. Начинающие разработчики пытаются заменить заглушками фрагменты тестируемой системы. Используются для разрыва зависимости. Проверка Invoice, ему требуется Customer, тому Address, тому City.
Позволяет проверять внутренние аспекты системы , которые снаружи проверить нельзя(например кэш) В отличии от моков не приводит к неудачному завершению теста при первом отклонении от ожидаемого поведения. Логирует все вызовы. На этапе проверки результатов тестовый агент предоставляет информацию о поступивших от тестируемой системы вызовах.
Объект , от которого зависит тестируемая система , заменяется специально созданным для теста объектом , проверяющим правильность своего использования со стороны тестируемой системы. Часто используется , когда невозможно наблюдать побочные эффекты. Ожидаемое поведение описывается до вызова тестируемой системы. Начинающим разработчикам сложнее писать и понимать такие тесты. Одного этого фактора достаточно , чтобы отдавать предпочтения тестам на основе тестовых агентов( Test Spy) В системе должен быть один тест в той конфигурации , при которой она будет работать в промышленной конфигурации. Приводит к хрупким тестам. Спецификация ожидаемого поведения
Инкапсуляция доступа к базе данных. Затем используем хэш таблицу. Частая причина – недоступность настоящего вызываемого компонента , его недостаточное быстродействие или недоступность в тестовой среде.
